抽象工厂模式

试着总结一下学过的设计模式，就由创建型模式说起吧。

意图
提供一个创建一系列相关活相互依赖对象的接口，而无需指定他们具体的类。(G4)

任务
假设我们需要进行各种数据库操作，可是我们有很多的选择啊，JDBC，Hibernate，Ibatis等等。本来选择一个就OK了，可是变态的Boss为了炫耀我们的技术如何如何强大，竟说我们能够无成本地在这三个解决方案间切换。这下系统该怎么设计呢？
或许你已经注意到 每种解决方案自身都是完备而独立的，不错，这便是解决问题的切入点。提供一套解决方案公有行为的接口，各个解决方案分别实现这些接口，同时建立一个创建各个解决方案的工厂(Factory)。这不就完成任务了吗？哈哈。

首先我们从使用者的角度出发，总结出一套数据库操作的方法，在这里我们称为 Service。假设我们只需要一个行为，就是work()，内容是打印出这是来自哪个解决方案。

java 代码

 

1. /** 
2.  * 业务类接口  
3.  */  
4. public interface Service {  
5.     /** 
6.      * 运行业务 
7.      */  
8.     void work();  
9. }  

然后我们根据这个接口分别实现各个解决方案的相应实现。

java 代码

 

1. /** 
2.  * A体系中的业务实现
   
3.  */  
4. public class ServiceA implements Service {  
5.   
   
6.     public void work() {  
7.         System.out.println("这是A体系中业务。");  
8.     }  
9. }  

java 代码

 

1. /** 
2.  * B体系中的业务实现
   
3.  */  
4. public class ServiceB implements Service {  
5.    
6.     public void work() {  
7.         System.out.println("这是B体系中业务。");  
8.     }  
9. }  

大概各位都碰到过需求不断变更，Service不断增加的情况吧。只有一个Service可不够用啊，保不准等会儿Boss就调研回来，需要新增加一个Service2，Service3......ServiceN。如果都写到Service接口里，那可是变成巨无霸了。汉堡包巨无霸我喜欢，代码巨无霸我可就不喜欢了。于是给这些Service建立一个 工厂(Factory)，以方便地创建各种Service。
那么我们首先来建立一个Factory的接口类。

java 代码

 

1. /** 
2.  *  工厂接口
   
3.  */  
4. public interface Factory {  
5.     /** 
6.      * 建立创建Service的抽象接口，由各实现的工厂来创建具体的Service 
7.      */  
8.      Service createService();  
9. }  

下面就来实现各个解决方案的工厂。

java 代码

 

1. /** 
2.  * 具体的实现工厂A 
3.  */  
4. public class FactoryA implements Factory {  
5.   
6.     public Service createService() {  
7.         // 创建本体系中的Service实现  
8.         return new ServiceA();  
9.     }  
10. }  

java 代码

 

1. /** 
2.  * 具体的实现工厂B
   
3.  */  
4. public class FactoryB implements Factory {   
5.     
   
6.     public Service createService() {  
7.         // 创建本体系中的Service实现  
8.         return new ServiceB();  
9.     }  
10. }  

或许各位看官会说这不就是工厂模式嘛，怎么又在前面加上“抽象”二字，难不成是故弄玄虚？非也非也。前头说过了，我们解决问题的切入点是“每种解决方案自身都是完备而独立的”，所以这些具体的各种解决方案的工厂对Consumer也应该是透明的。于是我们给这些工厂(解决方案)加上一个工厂，也就是我们通过这个工厂来生成一整套的解决方案。这个工厂便是我们要说的 AbstractFactory。

java 代码

 

1. /** 
2.  *  抽象工厂
   
3.  */  
4. public  class AbstractFactory {  
5.     /** 
6.      * 根据不同的体系要求创建出不同的业务工厂 
7.      *  
8.      * @param factoryName 
9.      * @return 
10.      */  
11.     public static AbstractFactory getFactory(String factoryName) {  
12.         AbstractFactory ist = null;  
13.         if (factoryName.equalsIgnoreCase("A")) {  
14.             ist = new FactoryA();  
15.         } else if (factoryName.equalsIgnoreCase("B")) {  
16.             ist = new FactoryB();  
17.         }  
18.         return ist;  
19.     }  
20. }  

本着重构的精神，也为了给点事 AbstractFactory做，我便把它和接口Factory合而为一，成为一个抽象类。大概这便是这种设计模式名字的由来吧。呵呵。

java 代码

 

1. /** 
2.  *  抽象工厂
   
3.  */  
4. public abstract class AbstractFactory {  
5.     /** 
6.      * 根据不同的体系要求创建出不同的业务工厂 
7.      *  
8.      * @param factoryName 
9.      * @return 
10.      */  
11.     public static AbstractFactory getFactory(String factoryName) {  
12.         AbstractFactory ist = null;  
13.         if (factoryName.equalsIgnoreCase("A")) {  
14.             ist = new FactoryA();  
15.         } else if (factoryName.equalsIgnoreCase("B")) {  
16.             ist = new FactoryB();  
17.         }  
18.         return ist;  
19.     }  
20.   
21.     /** 
22.      * 建立创建Service的抽象接口，由各实现的工厂来创建具体的Service 
23.      */  
24.     public abstract Service createService();  
25. }  

相应的，FactoryA和FactoryB修改为

java 代码

 

1. public class FactoryA extends AbstractFactory {  
2.   ......  
3. }  
4.   
5. public class FactoryB extends AbstractFactory {  
6.   ......  
7. }  

这样，各种解决方案间的切换便十分容易了。

java 代码

 

1. /** 
2.  * 业务的消费者 
3.  *  
4.  * @author 聪明的笨蛋 
5.  * @email lintomny@gmail.com 
6.  */  
7. public class Consumer {  
8.     public void work() {  
9.         Service service = null;  
10.   
11.         // 实现A体系中的业务  
12.         service = AbstractFactory.getFactory("A").createService();  
13.         service.work();  
14.   
15.         // 实现B体系中的业务  
16.         service = AbstractFactory.getFactory("B").createService();  
17.         service.work();  
18.     }  
19.   
20.         //运行  
21.     public static void main(String[] args) {  
22.         Consumer csm = new Consumer();  
23.         csm.work();  
24.     }  
25. }  

恩，Mission completed！剩下的就是各个解决方案的实现了，哈哈。那些工作就让，就让.......没有人做，还是我做吧.....谁叫俺是小弟呢。唉~

小结
正如我上面举的这个例子，抽象工厂模式主要适用于需要提供若干种不同实现体系，但又要求有相同处理要求的时候。如Portal技术中，各种Portlet便是不同的体系，但我们在处理Portal的时候都是把他们统一当作Portlet实现，同样这种解决问题的思路可以用在SOA中。这种设计模式大多出现在各个系统进行集成的时候。

题外话
对于上面的抽象工厂中，AbstractFactory依赖于其各子类Factory，这是不合适的。因为这样一来，我们的工程中如果只使用其中一种Factory时，却不得不背上其他用不上的Factory。在这里多做一些改进工作，使用类似于spring中管理bean的方式，对各Factory进行管理。

首先我们需要规定好一种管理格式，在这里以xml为例吧。

xml 代码

 

<beans>     <bean id="A" class="com.javaeye.smartfool.FactoryA" />     <bean id="B" class="com.javaeye.smartfool.FactoryB" />   </beans>  

这样，我们可以在AbstractFactory加入一个读配置的方法getXmlClass，通过输入id值来读出其对应的class名。这样，我们的AbstractFactory变成

java 代码

 

public abstract class AbstractFactory {          // 读取配置文件       private static String getXmlClass(String id){           ......       }              public static AbstractFactory getFactory(String factoryName) {           AbstractFactory ist = null;           String className = getXmlClass(factoryName);           try {               ist = (AbstractFactory) Class.forName(className).newInstance();           } catch (Exception e) {               e.printStackTrace();               ist = null;           }            return ist;       }          public abstract Service createService();   }  

这样，就可以解除AbstractFactory对子类的依赖了。

更多的关于此类依赖的设计实践可以参考without ejb这书，上面有很多非常好的思想，绝对能受益非浅。