设计模式--抽象工厂之新解

 

 

动  机

设计模式相信大家早已不再陌生，尤其在Java语言被广泛使用以后 ，GoF设计模式更是被广大Java程序员所熟知。
抽象工厂模式作为GoF模式中最重要和最经典的一个模式 ，几乎无处不被使用。
但是你真正地完全理解了抽象工厂设计模式了吗？你能默写出一个抽象工厂框架吗？

看了许多抽象工厂设计模式的中文文档，总觉得阐述得还不够简单，文档格式的组织也不够良好，提供的代码不够完整，这都导致了读者要么没有耐心读完整篇文档，要么不能真正实践例子代码。

于是有了"新解"的想法，即虚拟一个足够简单的案例，尝试从一个全新的、更加通俗的角度去诠释它，并提供完整的可以运行的Eclipse工程去调试运行它，非常适合设计模式初学者。

虚拟案例

中国企业需要一项简单的财务计算：每月月底，财务人员要计算员工的工资。
员工的工资 = (基本工资 + 奖金 - 个人所得税)。这是一个放之四海皆准的运算法则。
为了简化系统，我们假设员工基本工资总是4000美金。

中国企业奖金和个人所得税的计算规则是:
	奖金 = 基本工资(4000) * 10%
	个人所得税 = (基本工资 + 奖金) * 40%

MaxDO软件公司要为此构建一个软件系统（代号叫Softo），满足中国企业的需求。

案例分析

奖金(Bonus)、个人所得税(Tax)的计算是Softo系统的业务规则(Service)
工资的计算(Calculator)则调用业务规则(Service)来计算员工的实际工资。
工资的计算作为业务规则的前端(或者客户端Client)将提供给最终使用该系统的用户(财务人员)使用。

针对中国企业为系统建模

根据上面的分析，为Softo系统建模如下:

图 1

相应业务规则(Service)类源码如下:

package com.maxdo.sample.service;
public class Constant {
	public static double BASE_SALARY = 4000;
}

//
package com.maxdo.sample.service.chinese;

import com.maxdo.sample.service.Constant;
public class ChineseTax{
	public double calculate() {
		return (Constant.BASE_SALARY + (Constant.BASE_SALARY * 0.1)) * 0.4;
	}
}

//
package com.maxdo.sample.service.chinese;

import com.maxdo.sample.service.Constant;
public class ChineseBonus{
	public double calculate(){
		return Constant.BASE_SALARY * 0.1;
	}	
}		

那么前端类Calculator源码如下:

package com.maxdo.sample.client;
import com.maxdo.sample.service.*;
import com.maxdo.sample.service.chinese.*;

public class Calculator {
	public static void main(String[] args) {
		ChineseBonus bonus = new ChineseBonus();
		double bonusValue  = bonus.calculate();
		
		ChineseTax tax = new ChineseTax();
		double taxValue = tax.calculate();
		
		double salary = 4000 + bonusValue - taxValue; 
		System.out.println("Salary is " + salary);
	}
 }

运行Calculator,输出结果如下:

Salary is 2640.0

针对美国企业为系统建模

问题提出

为了拓展国际市场,MaxDO要把该系统移植给美国公司使用。
美国企业的工资计算同样是: 员工的工资 = 基本工资 + 奖金 - 个人所得税。
但是他们的奖金和个人所得税的计算规则不同于中国企业:

美国企业奖金和个人所得税的计算规则是:
        奖金 = 基本工资 * 15 %
                个人所得税 = (基本工资 * 5% + 奖金 * 25%)  

解决方案

根据前面为中国企业建模经验，我们仅仅将ChineseTax、ChineseBonus修改为AmericanTax、AmericanBonus。 修改后的模型如下：

图 2

相应业务规则(Service)源码如下:

package com.maxdo.sample.service;
public class Constant {
	public static double BASE_SALARY = 4000;
}

//
package com.maxdo.sample.service.american;

import com.maxdo.sample.service.Bonus;
import com.maxdo.sample.service.Constant;

public class AmericanBonus{
	public double calculate(){
		return Constant.BASE_SALARY * 0.15;
	}	
}

//
package com.maxdo.sample.service.american;

import com.maxdo.sample.service.Constant;

//
public class AmericanTax{
	public double calculate() {
		return (Constant.BASE_SALARY * 0.05 + Constant.BASE_SALARY * 0.25);
	}
} 			

前端类Calculator源码如下(红色的部分是被修正处):

package com.maxdo.sample;
public class Calculator {
	public static void main(String[] args) {
		AmericanBonus bonus = new AmericanBonus();
		double bonusValue  = bonus.calculate();
		
		AmericanTax tax = new AmericanTax();
		double taxValue = tax.calculate();
		
		double salary = 4000 + bonusValue - taxValue; 
		System.out.println("Salary is " + salary);
	}
} 

运行Calculator,输出结果如下:

Salary is 3400.0			

整合成通用系统

问题提出

让我们回顾一下该系统的发展历程：
最初，我们只考虑将Softo系统运行于中国企业。但随着MaxDO公司业务向海外拓展， MaxDO需要将该系统移植给美国使用。
移植时,MaxDO不得不抛弃中国企业的业务规则类ChineseTax和ChineseBonus， 然后为美国企业新建两个业务规则类: AmericanTax,AmericanBonus。最后修改了业务规则调用Calculator类。

结果我们发现：每当Softo系统移植的时候，就抛弃原来的类。现在，如果中国联想集团要购买该系统，我们不得不再次抛弃AmericanTax,AmericanBonus，修改回原来的业务规则。

解决方案

一个可以立即想到的做法就是在系统中保留所有业务规则模型，即保留中国和美国企业工资运算规则。

图 3

通过保留中国企业和美国企业的业务规则模型，如果该系统在美国企业和中国企业之间切换时，我们仅仅需要修改Caculator类即可。

让移植工作更简单——面向接口

问题提出

前面系统的整合问题在于：当系统在客户在美国和中国企业间切换时仍然需要修改Caculator代码。
一个维护性良好的系统应该遵循“开闭原则”。即：封闭对原来代码的修改，开放对原来代码的扩展（如类的继承，接口的实现）

解决方案

MaxDO发现不论是中国企业还是美国企业，他们的业务运规则都采用同样的计算接口。 于是很自然地想到建立两个业务接口类Tax，Bonus，然后让AmericanTax、AmericanBonus和ChineseTax、ChineseBonus分别实现这两个接口， 据此修正后的模型如下:

图 4

修改后的Calculator代码如下:

package com.maxdo.sample;

import com.maxdo.sample.service.*;
import com.maxdo.sample.service.american.*;

public class Calculator {
	public static void main(String[] args) {
		Bonus bonus = new AmericanBonus();
		double bonusValue  = bonus.calculate();
		
		Tax tax = new AmericanTax();
		double taxValue = tax.calculate();
		
		double salary = 4000 + bonusValue - taxValue; 
		System.out.println("Salary is " + salary);
	}
}
				

显然，系统经过改造，当它在美国和中国企业间切换时Caculator代码的修改量减少了(不必修改绿色的部分)。

为业务规则增加工厂方法

问题提出

然而，上面增加的接口几乎没有解决任何问题，因为当系统的客户在美国和中国企业间切换时Caculator代码仍然需要修改。

只不过修改少了两处，但是仍然需要修改红色代码部分。致命的问题是：MaxDO常常将这个移植工作转包给一个叫Hippo的软件公司。 由于版权问题,MaxDO并未提供Softo系统的源码给Hippo公司，因此Hippo公司根本无法修改Calculator，导致实际上移植工作无法进行。

解决方案

为此，MaxDO考虑增加一个工具类(命名为Factory)，代码如下:

package com.maxdo.sample.service;

import com.maxdo.sample.service.chinese.*;

public class Factory {
	public Tax createTax(){
		return new ChineseTax();
	}
	public Bonus createBonus(){
		return new ChineseBonus();
	}
}	
				

那么修改后的Caculator看起来如下:

package com.maxdo.sample;

import com.maxdo.sample.service.*;
import com.maxdo.sample.service.american.*;

public class Calculator {
	public static void main(String[] args) {
		Bonus bonus = new Factory().createBonus();
		double bonusValue  = bonus.calculate();
		
		Tax tax = new Factory().createTax();
		double taxValue = tax.calculate();
		
		double salary = 4000 + bonusValue - taxValue; 
		System.out.println("Salary is " + salary);
	}
}

不错，MaxDO解决了一个大问题，设想一下：当该系统从中国企业移植到美国企业时，我们现在需要做什么？
答案是: 对于Caculator类我们什么也不用做。我们需要做的是修改Factory类的红色部分，修改结果如下: 

package com.maxdo.sample;

import com.maxdo.sample.service.american.*;

public class Factory {
	public Tax createTax(){
		return new AmericanTax();
	}
	public Bonus createBonus(){
		return new AmericanBonus();
	}
}

为系统增加抽象工厂方法

问题提出

很显然，前面的解决方案带来了一个副作用：就是系统不但增加了新的类Factory，而且当系统移植时，移植工作仅仅是转移到Factory类上，工作量并没有任何缩减，而且还是要修改系统的源码。 从Factory类在系统移植时修改的内容我们可以看出: 实际上它是专属于美国企业或者中国企业的。名称上应该叫AmericanFactory,ChineseFactory更合适.

解决方案

解决方案是增加一个抽象工厂类AbstractFactory，增加一个静态方法，该方法根据一个配置文件(可以是XML/Properties文件) 一个项(比如factoryName)动态地判断应该实例化哪个工厂类，这样，我们就把移植工作转移到了对配置文件的修改。修改后的模型和代码.

图 5

抽象工厂类的代码如下:

package com.maxdo.sample.service;

import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.util.Properties;

import com.maxdo.sample.service.chinese.*;
import com.maxdo.sample.service.american.*;

abstract public class AbstractFactory {
	abstract public Tax createTax();
	abstract public Bonus createBonus();
	public static AbstractFactory getInstance(){
		AbstractFactory instance = null;

		Properties prop = new Properties();
		InputStream stream = null;
		try {
			// 从config.properties读取factoryName项的值
			stream = new FileInputStream("config.properties");
			prop.load(stream);
		}catch(IOException e){
			e.printStackTrace();
		}
		String factoryName = prop.getProperty("factoryName");
		
		//  根据FactoryName的值决定实例化哪一个工厂类
		if(factoryName.equals("American")){
			return new AmericanFactory();
		}
		else if(factoryName.equals("Chinese")){
			return new ChineseFactory();
		}
		return instance;		
	}
}	

config.properties内容如下:

factoryName=Chinese				

采用上面的解决方案，当系统在美国企业和中国企业之间切换时，我们需要做什么移植工作？

答案是: 我们仅仅需要修改配置文件config.proerties，将factoryName的值改为American。
修改config.properties的工作很简单， MaxDO的工程师只要写一篇幅配置文档说明书提供给移植该系统的团队(比如Hippo公司) 就可以方便地切换使该系统运行在美国或中国企业。

最后的修正（不是最终方案）

问题提出

前面的解决方案几乎很完美，但是还有一点瑕疵，瑕疵虽小，但可能是致命的。

考虑一下，现在日本NEC公司决定购买该系统，NEC公司的工资的运算规则遵守的是日本的法律。如果采用上面的系统构架，这个移植我们要做哪些工作呢?

1. 增加新的业务规则类JapaneseTax,JapaneseBonus分别实现Tax和Bonus接口。
2. 修改AbstractFactory的getInstance方法，增加else if(factoryName.equals("Japanese")){....

注意: 系统中增加业务规则类不是模式所能解决的，无论采用什么设计模式，JapaneseTax,JapaneseBonus总是少不了的。

我们真正不能接受的是：我们仍然修要修改系统中原来的类(AbstractFactory)。前面提到过该系统的移植工作，MaxDO可能转包给一个叫Hippo的软件公司。 为了维护版权，MaxDO未将该系统的源码提供给Hippo公司，那么Hippo公司根本无法修改AbstractFactory，所以系统移植其实无从谈起，或者说系统移植总要MaxDO亲自参与。

解决方案

解决方案是将AbstractFactory的getInstance方法的if/else改变为java类反射方式实现，修正后的AbstractFactory代码如下:

package com.maxdo.sample.service;

import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.util.Properties;

abstract public class AbstractFactory {
	abstract public Tax createTax();
	abstract public Bonus createBonus();
	public static AbstractFactory getInstance(){
		AbstractFactory instance = null;

		Properties prop = new Properties();
		InputStream stream = null;
		try {
			stream = new FileInputStream("config.properties");
			prop.load(stream);
		}catch(IOException e){
			e.printStackTrace();
		}
		String factoryName = prop.getProperty("factoryName");
		try {
			
		     instance = (AbstractFactory)Class.forName(factoryName).newInstance();
			
		} catch (Exception e) {
			e.printStackTrace();
			instance = null;
		}
		return instance;		
	}
}
			

注意源码中红色部分，得益于JAVA这个API提供的反射机制，我们才得以这么做。
配合java反射机制，你需要修改config.properties文件的factoryName值为实际的类名:

#factoryName=Chinese
factoryName=com.maxdo.sample.service.chinese.ChineseFactory	

总  结

图5是最终版的系统模型图。我们发现作为客户端角色的Calculator仅仅依赖com.maxdo.sample.service包， 它不必去理解中国和美国企业具体的业务规则如何实现，Calculator面对的仅仅是业务规则接口Tax和Bonus。

Softo系统的实际开发的分工可能是一个团队专门做业务规则，另一个团队专门做前端的业务规则组装。 抽象工厂模式有助于这样的团队的分工: 两个团队通讯的约定是业务接口，由抽象工厂作为纽带粘合业务规则和前段调用，大大降低了模块间的耦合性，提高了团队开发效率。

抽象工厂模式的实现得益于OO语言的特性。对于Java语言，相应的的特性是：

1. Java的接口特性: 比如,Tax obj = new ChineseTax();
   实例化一个真正的类ChineseTax，然后返回一个接口Tax。这个是Java的基础知识，如果你还不能明白，我建议你先去看看一些Java编程的基础书籍。
2. Java的类反射机制:　Class.forName("RealClassName").newInstance();
   正是因为这个API，我们才得以将系统的移植(实际是实现类的切换)转移到配置文件的字符串修改上面。

Java世界几乎所有的组件都有抽象工厂模式。完完全全地理解抽象工厂模式的意义非常重大，可以说对它的理解是你对OOP理解上升到一个新的里程碑的重要标志。 学会了用抽象工厂模式编写框架类，你将理解OOP的精华:面向接口编程.。

完整的代码请在这里下载。