Java设计模式之一工厂模式

工厂模式：

一、引子
              话说十年前，有一个用户，他家有三辆汽车——Benz奔驰、Bmw宝马、Audi奥迪，还雇了司机为他开车。不过，用户坐车时总是怪怪的：上 Benz车后跟司机说“开奔驰车！”，
              坐上Bmw后他说“开宝马车！”，坐上Audi说“开奥迪车！”。你一定说：这人有病！直接说开车不就行了？！ 而当把这个用户的行为放到我们程序设计中来时，会发现这是一个
              普遍存在的现象。幸运的是，这种有病的现象在OO（面向对象）语言中可以避免了。下面就以Java语言为基础来引入我们本文的主题：工厂模式。

二、工厂模式分为：

工厂模式主要是为创建对象提供过渡接口，以便将创建对象的具体过程屏蔽隔离起来，达到提高灵活性的目的。

1、简单工厂模式（Simple Factory） ：又称静态工厂方法模式，重命名上就可以看出这个模式一定很简单。它存在的目的很简单：定义一个用于创建对象的接口。 但不利于产生系列产品。
在简单工厂模式中,一个工厂类处于对产品类实例化调用的中心位置上,它决定那一个产品类应当被实例化, 如同一个交通警察站在来往的车辆流中,决定放行那一个方向的车辆向那一个方向流动一样。

Simple Factory 模式角色组成：
1) 工厂类角色：这是本模式的核心，含有一定的商业逻辑和判断逻辑。在java中它往往由一个具体类实现。
         2) 抽象产品角色：它一般是具体产品继承的父类或者实现的接口。在java中由接口或者抽象类来实现。
         3) 具体产品角色：工厂类所创建的对象就是此角色的实例。在java中由一个具体类实现。
        
         下面我们从开闭原则（对扩展开放；对修改封闭）上来分析下简单工厂模式：
         当用户增加了一辆车的时候，只要符合抽象产品制定的合同，那么只要通知工厂 类知道就可以被客户使用了。所以对产品部分来说，它是符合开闭原则的；但是工厂部分好像不太理想，
         因为每增加一辆车，都要在工厂类中增加相应的业务逻辑或 者判断逻辑，这显然是违背开闭原则的。可想而知对于新产品的加入，工厂类是很被动的。对于这样的工厂类（在我们的例子
         中是为CarFactory），我们称它为全能类或者上帝类。
         我们举的例子是最简单的情况，而在实际应用中，很可能产品是一个多层次的树状结构。由于简单工厂模式中只有一个工厂类来对应这些产品，所以这可能会把我们的上帝累坏了，也累
         坏了我们这些程序员，于是工厂方法模式作为救世主出现了；
       
       
        2、工厂方法模式（Factory Method）：又称为多形性工厂，工厂方法模式去掉了简单工厂模式中工厂方法的静态属性，使得它可以被子类继承。这样在简单工厂模式里集中在工厂方法上的压力可以由工厂方法模
        式里不同的工厂子类来分担。工厂方法模式是简单工厂模式的进一步抽象化和推广，工厂方法模式里不再只由一个工厂类决定那一个产品类应当被实例化,这个决定被交给抽象工厂的子类去做。
       
        Factory Method模式角色组成：
        1)抽象工厂角色： 这是工厂方法模式的核心，它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在java中它由抽象类或者接口来实现。
     2)具体工厂角色：它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象。
       3)抽象产品角色：它是具体产品继承的父类或者是实现的接口。在java中一般有抽象类或者接口来实现。
       4)具体产品角色：具体工厂角色所创建的对象就是此角色的实例。在java中由具体的类来实现。
      
       工厂方法模式使用继承自抽象工厂角色的多个子类来代替简单工厂模式中的“上帝类”。正如上面所说，这样便分担了对象承受的压力；而且这样使得结构变得灵活 起来——当有新的产品（
       即用户的汽车）产生时，只要按照抽象产品角色、抽象工厂角色提供的合同来生成，那么就可以被客户使用，而不必去修改任何已有的代 码。可以看出工厂角色的结构也是符合开闭原则的！
      
       可以看出工厂方法的加入，使得对象的数量成倍增长。当产品种类非常多时，会出现大量的与之对应的工厂对象，这不是我们所希望的。因为如果不能避免这种情 况，可以考虑使用简单工厂
       模式与工厂方法模式相结合的方式来减少工厂类：即对于产品树上类似的种类（一般是树的叶子中互为兄弟的）使用简单工厂模式来实现。
      
      
       3、简单工厂模式与工厂方法模式小结：
      
       工厂方法模式仿佛已经很完美的对对象的创建进行了包装，使得客户程序中仅仅处理抽象产品角色提供的接口。那我们是否一定要在代码中遍布工厂呢？大可不必。也许在下面情况下你可以
       考虑使用工厂方法模式：
     1)当客户程序不需要知道要使用对象的创建过程。
     2)客户程序使用的对象存在变动的可能，或者根本就不知道使用哪一个具体的对象。
简单工厂模式与工厂方法模式真正的避免了代码的改动了？没有。在简单工厂模式中，新产品的加入要修改工厂角色中的判断语句；而在工厂方法模式中，要么将判断逻辑留在抽象工厂角色
中，要么在客户程序中将具体工厂角色写死（就象上面的例子一样）。而且产品对象创建条件的改变必然会引起工厂角色的修改。 面对这种情况，Java的反射机制与配置文件的巧妙结合突破
了限制——这在Spring中完美的体现了出来。

工厂方法模式和简单工厂模式在定义上的不同是很明显的。工厂方法模式的核心是一个抽象工厂类,而不像简单工厂模式, 把核心放在一个实类上。工厂方法模式可以允许很多实的工厂类从抽象
工厂类继承下来, 从而可以在实际上成为多个简单工厂模式的综合,从而推广了简单工厂模式。反过来讲,简单工厂模式是由工厂方法模式退化而来。设想如果我们非常确定一个系统只需要一个实
的工厂类, 那么就不妨把抽象工厂类合并到实的工厂类中去。而这样一来,我们就退化到简单工厂模式了。

4、抽象工厂模式（Abstract Factory）：又称为工具箱，产生产品族，但不利于产生新的产品

什么是产品族： 位于不同产品等级结构中，功能相关联的产品组成的家族。还是让我们用一个例子来形象地说明一下吧。回到抽象工厂模式的话题上。可以说，抽象工厂模式和工厂方法模式的
区别就在于需要创建对象的复杂程度上。而且抽象工厂模式是三个里面最为抽象、最具一般性的。 抽象工厂模式的用意为：给客户端提供一个接口，可以创建多个产品族中的产品对象。

使用抽象工厂模式还要满足一下条件：
     1)系统中有多个产品族，而系统一次只可能消费其中一族产品。
             2)同属于同一个产品族的产品以其使用。
            
Abstract Factory模式角色组成（和工厂方法的如出一辙）：
     1)抽象工厂角色： 这是工厂方法模式的核心，它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在java中它由抽象类或者接口来实现。
     2)具体工厂角色：它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象。在java中它由具体的类来实现。
     3)抽象产品角色：它是具体产品继承的父类或者是实现的接口。在java中一般有抽象类或者接口来实现。
     4)具体产品角色：具体工厂角色所创建的对象就是此角色的实例。在java中由具体的类来实现。 
    
     在抽象工厂模式中，抽象产品 (AbstractProduct) 可能是一个或多个，从而构成一个或多个产品族(Product Family)。 在只有一个产品族的情况下，抽象工厂模式实际上退化到工厂方法模式。
    
三、总结

三种模式从上到下逐步抽象，并且更具一般性。GOF在《设计模式》一书中将工厂模式分为两类：工厂方法模式（Factory Method）与抽象工厂模式（Abstract Factory）。将简单工厂模式
（Simple Factory）看为工厂方法模式的一种特例，两者归为一类。

（1）简单工厂模式是由一个具体的类去创建其他类的实例，父类是相同的，父类是具体的。
（2）工厂方法模式是有一个抽象的父类定义公共接口，子类负责生成具体的对象，这样做的目的是将类的实例化操作延迟到子类中完成。
（3）抽象工厂模式提供一个创建一系列相关或相互依赖对象的接口，而无须指定他们具体的类。它针对的是有多个产品的等级结构。而工厂方法模式针对的是一个产品的等级结构。

四、个人总结
总结之前，先说两个概念，请确保理解，如下：
1. 产品：具体到某一实例，如：宝马，奔驰，J20，F35等；
2. 产品族：具体到某一类产品，如：汽车（Car），飞机（Plane）等；

简单工厂模式（Simple Factory）：适用于同一产品族，固定产品种类的情况，优点：代码简单，缺点：不利于增加新产品，需修改原有工厂代码；
工厂方法模式（Factory Method）：适用于同一产品族，可变产品种类的情况，优点：代码简单，利于增加新产品，无需修改原有工厂代码，缺点：子工厂类遍布各处，子工厂类易泛滥；
抽象工厂模式（Abstract Factory）：适用于不同产品族情况，优点：可生产不同产品族的产品，缺点：不利于增加新产品，即使在工厂类：ProductFactoryByFactory中，使用了调用产品
  Factory创建对象，在增加新产品时，依然违背了不修改原有工厂代码的原则；

五、延伸阅读

Java的开闭原则：一个软件系统应该对开展时开放的，对修改时关闭的（Software entity should be open for extension, but closed for modification）；在设计一个模块的时候，应该
可以使这个模块可以在不被修改的前提下被扩张。换言之，应该可以在不必修改源代码的情况下改变这个模块的行为。

听上去很矛盾，但是通过一些使用一些设计模式就可以轻松的做到，如 适配器模式（adapter）等等。满足了OCP（Open-Closed Principle）原则可以给软件系统带来两个无法比拟的设计目标：
  1.扩展性。通过扩展已有的软件系统，可以提供新的行为，以满足对软件的新需求。
  2.稳定性。已有的软件模块，特别是最重要的抽象层模块不能被修改，这就是变化中的软件系统有一定的稳定性和可延续性。
3.维护性大大提高。

怎么才能实现“开-闭”原则：
抽象化是关键
  解决问题的关键在于抽象化。在像java这样的面向对象的语言中，可以给系统定义出一个一劳永逸，不再更改的抽象设计，此设计允许有无穷无尽的实现，并且互不影响。在java语言中，给出一个
  抽象的类或者接口，规定出具体方法必须提供的方法特征作为系统设计的抽象层。这个抽象层预见了所有的可能扩展，因此，在任何扩展情况下都不会改变。这就使得系统的抽象层不需要修改，从
  而满足了“开-闭”原则的第二条：对修改是关闭的。
  同时，由于从抽象层导出一个或多个新的具体类来实现抽象类或者接口就可以改变系统的行为，因此系统的设计对扩展时开放的，这就满足了“开-闭”原则的第一条：对可变性的封装原则 。如何
  设计好抽象层的类或者接口，我们必须对系统的可变性进行封装。这就是所谓的”对可变性的封装原则"（Principle of Encapsulation of Variation short for EVP)对可变性的封装原则 讲的是找到
  一个系统的可变因素，将其封装起来。
“对可变性的封装原则”意味着两点：
  1.一种可变性不应散落在很多角落，而应当被封装到一个对象里面。
  2.一种可变性不应当与另一种可变性混合在一起。


相关代码，请见附件







      
      
        

评论

1 楼 taomingkai 2012-08-13