抽象工厂模式

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

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

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

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


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


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


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



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


本着重构的精神，也为了给点事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修改为



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


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

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

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

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


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


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

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

** 
/* 具体的实现工厂A 
*/  
public class FactoryA implements AbstractFactory {  
  
    public Service createService() {  
        // 创建本体系中的Service实现  
        return new ServiceA();  
    }  
}  

这里是不是应该实现Factory 接口啊，后来是去掉Factory，直接继承AbstractFactory了吧？

楼主的代码确实有问题，不过大致思想还是说清楚了

对于

service = AbstractFactory.getFactory("A").createService(); 

的做法不是很认同，应该更改为

service = new FactoryA().createService();

对于如下代码：

    public static AbstractFactory getFactory(String factoryName) {   
        AbstractFactory ist = null;   
        if (factoryName.equalsIgnoreCase("A")) {   
            ist = new FactoryA();   
        } else if (factoryName.equalsIgnoreCase("B")) {   
            ist = new FactoryB();   
        }   
        return ist;   
    }   

也不是很认同，从设计和继承原则来说，我觉得父类不应该依赖子类，如果依赖子类，不容易扩展.
如，我要添加一个新的工厂和新的Service,则还需要修改AbstractFactory,这不符合最终使用工厂模式的目的.

下面说说我对工厂模式的理解,我觉得应该将工厂方法和抽象工厂合并来谈.
什么时候应该使用工厂方法,什么时候应该使用抽象工厂?
我觉得,当一个产品有多个实现的时候应该考虑抽象工厂,否则应使用工厂方法,对于楼主的例子中的产品就是Service.
虽然很多抽象工厂的例子包含多个产品.但是我觉得选择工厂方法和抽象工厂不应该同产品的种类有任何关系。

下面的例子有多个产品系列，但是属于工厂方法，楼主的例子只有一个产品系列，但是属于抽象工厂。

interface ProductA{}

interface ProductB{}

class ConcreteProductA implements ProductA{}

class ConcreteProductB implements ProductB{}

interface Factory{
   public ProductA createProcuctA();
   public ProductB createProcuctB();
}

class ConcreteFactory implements Factory(){
   public ProductA createProcuctA()
   {
   	return new ConcreteProductA();
   }
   public ProductB createProcuctB()
   {
   	return new createProcuctB();
   }
}

class Test{
   methoda{
      //这里没有考虑工厂需要singleton的情况
      ProductA = new ConcreteFactory().createProcuctA();
      ProductB = new ConcreteFactory().createProcuctB();
   }
}

以上是我的个人理解,望批评指正.

确实是弄错了，不好意思。原文的代码是我事先写好的最终结果，把extends改回成implements，却忘了把AbstractFactory改回成Factory。已修改。

同意

模式,知道是这么回事就行了.

讲得都不咋地。一看就没有写过复杂的项目。
抽象工厂使用应该是被逼出来的，而不是想像出来的。
如果没有足够的编码经验，最好刻意去运用某种模式。
只要不断消除代码中的重复味道，多写一些复杂一点的项目，一定可以学会抽象工厂。
就这么简单。

我也同意，补充了关于这方面一个解决方法。由于不属于AbstractFactory这个设计模式本身的内容，就把它作为题外话在原文末端加上了。

挺好的，学习楼主分享，学习java，模式很是重要。
学习中。。。