设计模式 之 工厂模式总结

依旧是拾人牙慧，以前看过Head first的设计模式，不过只知道了些概念，要编写起来还是得Google，我这破脑袋哈~~

不过这次仔细阅读了下工厂模式的东东，也把它写到了代码之中，算是有了一定的了解了。

下面是结合两篇博客的总结~~

http://blog.csdn.net/ai92/article/details/209198

http://blog.csdn.net/ipqxiang/article/details/1955677

依旧拷贝一遍 防丢~

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

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

　　工厂模式在《Java与模式》中分为三类：

　　　　1）简单工厂模式（Simple Factory）

　　　　2）工厂方法模式（Factory Method）

　　　　3）抽象工厂模式（Abstract Factory）

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

两者皆可，在本文使用《Java与模式》的分类方法。下面来看看这些工厂模式是怎么来“治病”的。

ps: 工厂模式是用来封装对象的生成的。。

三、简单工厂模式

简单工厂模式又称静态工厂方法模式。重命名上就可以看出这个模式一定很简单。它存在的目的很简单：定义一个用于创建对象的接口。
       先来看看它的组成：

　　　　1)工厂类角色：这是本模式的核心，含有一定的商业逻辑和判断逻辑。在java中它往往由一个具体类实现。

　　　　2)抽象产品角色：它一般是具体产品继承的父类或者实现的接口。在java中由接口或者抽象类来实现。

　　　　3)具体产品角色：工厂类所创建的对象就是此角色的实例。在java中由一个具体类实现。

 ps: 上面都是虚的，直接看类图

来用类图来清晰的表示下的它们之间的关系： 

 

ps: 懒得给图加点料了，图中Creator就是工厂类，然后ConcreteProduct就是抽象产品，Product是具体产品。构建时Creator用来控制生成对象，并返回ConcreteProduct抽象接口就可以。（Product具体产品需要实现ConcreteProduct的接口）

那么简单工厂模式怎么来使用呢？我们就以简单工厂模式来改造暴发户坐车的方式——现在暴发户只需要坐在车里对司机说句：“开车”就可以了。

//抽象产品角色
public interface Car
{
    public void drive(); 
}
//具体产品角色
public class Benz implements Car
{
    public void drive() //实现抽象产品接口 
    {
        System.out.println("Driving Benz ");
    }
}
//具体产品
public class Bmw implements Car
{
    public void drive()  
    {
        System.out.println("Driving Bmw ");
    }
}
。。。（奥迪我就不写了:P）
//工厂类角色
public class Driver
{
    //工厂方法.注意 返回类型为抽象产品角色
    public static Car driverCar(String s)throws Exception    
    {
        //判断逻辑，返回具体的产品角色给Client
        if(s.equalsIgnoreCase("Benz"))  
            return new Benz();
        else if(s.equalsIgnoreCase("Bmw"))
            return new Bmw();
        ......   
        else throw new Exception();
     }
}
//欢迎暴发户出场......
public class Magnate
{
     public static void main(String[] args)
    {
        try
        { 
            //告诉司机我今天坐奔驰              
            Car car = Driver.driverCar("benz"); 
            //下命令：开车                   
            car.drive();
            ....                

    将本程序空缺的其他信息填充完整后即可运行。如果你将所有的类放在一个文件中，请不要忘记只能有一个类被声明为public。本程序在jdk1.4 下运行通过。

      程序中各个类的关系表达如下：

这便是简单工厂模式了。怎么样，使用起来很简单吧？那么它带来了什么好处呢？
       首先，使用了简单工厂模式后，我们的程序不在“有病”，更加符合现实中的情况；而且客户端免除了直接创建产品对象的责任，而仅仅负责“消费”产品（正如暴发户所为）。

       下面我们从开闭原则（对扩展开放；对修改封闭）上来分析下简单工厂模式。当暴发户增加了一辆车的时候，只要符合抽象产品制定的合同，那么只要通知工厂类知道就可以被客户使用了。所以对产品部分来说，它是符合开闭原则的；但是工厂部分好像不太理想，因为每增加一辆车，都要在工厂类中增加相应的业务逻辑或者判断逻辑，这显然是违背开闭原则的。可想而知对于新产品的加入，工厂类是很被动的。对于这样的工厂类（在我们的例子中是为司机师傅），我们称它为全能类或者上帝类。
       我们举的例子是最简单的情况，而在实际应用中，很可能产品是一个多层次的树状结构。由于简单工厂模式中只有一个工厂类来对应这些产品，所以这可能会把我们的上帝累坏了，也累坏了我们这些程序员:(
       于是工厂方法模式作为救世主出现了。 

四、工厂方法模式

       工厂方法模式去掉了简单工厂模式中工厂方法的静态属性，使得它可以被子类继承。这样在简单工厂模式里集中在工厂方法上的压力可以由工厂方法模式里不同的工厂子类来分担。

你应该大致猜出了工厂方法模式的结构，来看下它的组成：

　　1) 抽象工厂角色： 这是工厂方法模式的核心，它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在java中它由抽象类或者接口来实现。

　　2) 具体工厂角色：它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象。

　　3) 抽象产品角色：它是具体产品继承的父类或者是实现的接口。在java中一般有抽象类或者接口来实现。

　　4) 具体产品角色：具体工厂角色所创建的对象就是此角色的实例。在java中由具体的类来实现。

ps: 把工厂也抽象了~有个工厂接口（有个变身欧特曼的方法~调用它~然后就出现不同的欧特曼了）

用类图来清晰的表示下的它们之间的关系：

工厂方法模式使用继承自抽象工厂角色的多个子类来代替简单工厂模式中的“上帝类”。正如上面所说，这样便分担了对象承受的压力；而且这样使得结构变得灵活起来——当有新的产品（即暴发户的汽车）产生时，只要按照抽象产品角色、抽象工厂角色提供的合同来生成，那么就可以被客户使用，而不必去修改任何已有的代码。可以看出工厂角色的结构也是符合开闭原则的！

       我们还是老规矩，使用一个完整的例子来看看工厂模式各个角色之间是如何来协调的。话说暴发户生意越做越大，自己的爱车也越来越多。这可苦了那位司机师傅了，什么车它都要记得，维护，都要经过他来使用！于是暴发户同情他说：看你跟我这么多年的份上，以后你不用这么辛苦了，我给你分配几个人手，你只管管好他们就行了！于是，工厂方法模式的管理出现了。代码如下：

//抽象产品角色，具体产品角色与简单工厂模式类似，只是变得复杂了些，这里略。
//抽象工厂角色，主要多了这么个东东
public interface Driver
{
     public Car driverCar();
}
public class BenzDriver implements Driver
{
     public Car driverCar()
    {
        return new Benz();
    }
}
public class BmwDriver implements Driver
{
    public Car driverCar()   
    {
        return new Bmw(); 
    }
}
//应该和具体产品形成对应关系...
//有请暴发户先生
public class Magnate
{
    public static void main(String[] args)
    {
        try
        { 
            Driver driver = new BenzDriver();
            Car car = driver.driverCar();
            car.drive();
        }
       ……
    }
} 

可以看出工厂方法的加入，使得对象的数量成倍增长。当产品种类非常多时，会出现大量的与之对应的工厂对象，这不是我们所希望的。因为如果不能避免这种情况，可以考虑使用简单工厂模式与工厂方法模式相结合的方式来减少工厂类：即对于产品树上类似的种类（一般是树的叶子中互为兄弟的）使用简单工厂模式来实现。

五、小结

工厂方法模式仿佛已经很完美的对对象的创建进行了包装，使得客户程序中仅仅处理抽象产品角色提供的接口。那我们是否一定要在代码中遍布工厂呢？大可不必。也许在下面情况下你可以考虑使用工厂方法模式：

　　1) 当客户程序不需要知道要使用对象的创建过程。

　　2) 客户程序使用的对象存在变动的可能，或者根本就不知道使用哪一个具体的对象。

简单工厂模式与工厂方法模式真正的避免了代码的改动了？没有。在简单工厂模式中，新产品的加入要修改工厂角色中的判断语句；而在工厂方法模式中，要么将判断逻辑留在抽象工厂角色中，要么在客户程序中将具体工厂角色写死（就象上面的例子一样）。而且产品对象创建条件的改变必然会引起工厂角色的修改。

ps:（个人观点错误请批）我认为其实对于简单的一般对象，对象的创建用工厂模式似乎有点鸡肋。对于一般对象创建，我认为可以让具体产品同时实现抽象工厂和抽象产品两个接口，这样会更加简洁。而对于有各种流程的对象创建，我觉得正是工厂方法的用武之地，比如一个产品有 状态读取、对象创建、初始化流程、载入流程 等等的一系列步骤，就可以将这些步骤封装到具体工厂中去，这是一个比较有效的做法。

       面对这种情况，Java的反射机制与配置文件的巧妙结合突破了限制——这在Spring中完美的体现了出来。

ps:在Java 6中有SPI机制，可以通过配置文件载入不同的类。不过网上对于SPI介绍比较千篇一律，没有具体的细节研究，故而我也只搞懂个大概，似乎连配置文件路径也是定死的（不知是否只能用在J2EE中）~~~没有写具体的测试代码~~以后要尝试哈~~童鞋~

六、抽象工厂模式

      先来认识下什么是产品族： 位于不同产品等级结构中，功能相关联的产品组成的家族。还是让我们用一个例子来形象地说明一下吧。

 

图中的BmwCar和BenzCar就是两个产品树（产品层次结构）；而如图所示的BenzSportsCar和BmwSportsCar就是一个产品族。他们都可以放到跑车家族中，因此功能有所关联。同理BmwBussinessCar和BenzSportsCar也是一个产品族。

 

图中一共有四个产品族，分布于三个不同的产品等级结构中。只要指明一个产品所处的产品族以及它所属的等级结构，就可以唯一的确定这个产品。

所谓的抽象工厂是指一个工厂等级结构可以创建出分属于不同产品等级结构的一个产品族中的所有对象。如果用图来描述的话，如下图：

ps:拼凑的，凑活看吧~

可以说，抽象工厂模式和工厂方法模式的区别就在于需要创建对象的复杂程度上。而且抽象工厂模式是三个里面最为抽象、最具一般性的。

抽象工厂模式的用意为：给客户端提供一个接口，可以创建多个产品族中的产品对象

而且使用抽象工厂模式还要满足一下条件：

　　1)系统中有多个产品族，而系统一次只可能消费其中一族产品。

　　2)同属于同一个产品族的产品以其使用。

来看看抽象工厂模式的各个角色（和工厂方法的如出一辙）：

　　1)抽象工厂角色： 这是工厂方法模式的核心，它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在java中它由抽象类或者接口来实现。

　　2)具体工厂角色：它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象。在java中它由具体的类来实现。

　　3)抽象产品角色：它是具体产品继承的父类或者是实现的接口。在java中一般有抽象类或者接口来实现。

　　4)具体产品角色：具体工厂角色所创建的对象就是此角色的实例。在java中由具体的类来实现。

类图如下：

图中描述的东西用产品族描述如下：

ps:这个抽象工厂，说简单简单，就是威力加强版的工厂方法；说难也难，一般比较难用到这个，平常学习练习的东东，谁去具体定义一个产品族，噔噔噔这么多项，还要把这么多项很清楚。

该程序演示了抽象工厂的结构，本身不具有任何实际价值。

// Abstract Factory pattern -- Structural example  
using System;

// "AbstractFactory"
abstract class AbstractFactory
{
  // Methods
  abstract public AbstractProductA CreateProductA();
  abstract public AbstractProductB CreateProductB();
}

// "ConcreteFactory1"
class ConcreteFactory1 : AbstractFactory
{
  // Methods
  override public AbstractProductA CreateProductA()
  {
    return new ProductA1();
  }
  override public AbstractProductB CreateProductB()
  {
    return new ProductB1();
  }
}

// "ConcreteFactory2"
class ConcreteFactory2 : AbstractFactory
{
  // Methods
  override public AbstractProductA CreateProductA()
  {
    return new ProductA2();
  }

  override public AbstractProductB CreateProductB()
  {
    return new ProductB2();
  }
}

// "AbstractProductA"
abstract class AbstractProductA
{
}

// "AbstractProductB"
abstract class AbstractProductB
{
  // Methods
  abstract public void Interact( AbstractProductA a );
}

// "ProductA1"
class ProductA1 : AbstractProductA
{
}

// "ProductB1"
class ProductB1 : AbstractProductB
{
  // Methods
  override public void Interact( AbstractProductA a )
  {
    Console.WriteLine( this + " interacts with " + a );
  }
}

// "ProductA2"
class ProductA2 : AbstractProductA
{
}

// "ProductB2"
class ProductB2 : AbstractProductB
{
  // Methods
  override public void Interact( AbstractProductA a )
  {
    Console.WriteLine( this + " interacts with " + a );
  }
}

// "Client" - the interaction environment of the products
class Environment
{
  // Fields
  private AbstractProductA AbstractProductA;
  private AbstractProductB AbstractProductB;

  // Constructors
  public Environment( AbstractFactory factory )
  {
    AbstractProductB = factory.CreateProductB();
    AbstractProductA = factory.CreateProductA();
  }
 
  // Methods
  public void Run()
  {
    AbstractProductB.Interact( AbstractProductA );
  }
}

/// <summary>
/// ClientApp test environment
/// </summary>
class ClientApp
{
  public static void Main(string[] args)
  {
    AbstractFactory factory1 = new ConcreteFactory1();
    Environment e1 = new Environment( factory1 );
    e1.Run();

    AbstractFactory factory2 = new ConcreteFactory2();
    Environment e2 = new Environment( factory2 );
    e2.Run();
  }
}

 

ps: 这么多代码 确实没什么价值。。。头都看晕了。。。其实也就抽象工厂1能够创建抽象产品*中的具体产品*1。。。好拗口。。。求通俗说法。。。

在以下情况下应当考虑使用抽象工厂模式：

• 一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节，这对于所有形态的工厂模式都是重要的。
• 这个系统有多于一个的产品族，而系统只消费其中某一产品族。
• 同属于同一个产品族的产品是在一起使用的，这一约束必须在系统的设计中体现出来。
• 系统提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于实现。

"开放－封闭"原则要求系统对扩展开放，对修改封闭。通过扩展达到增强其功能的目的。对于涉及到多个产品族与多个产品等级结构的系统，其功能增强包括两方面：

增加产品族：Abstract Factory很好的支持了"开放－封闭"原则。

增加新产品的等级结构：需要修改所有的工厂角色，没有很好支持"开放－封闭"原则。

综合起来，抽象工厂模式以一种倾斜的方式支持增加新的产品，它为新产品族的增加提供方便，而不能为新的产品等级结构的增加提供这样的方便。

 

ps: 总算完了。。。我这初出茅庐阶段的。。。。还是停留在工厂方法阶段吧。。。。抽象工厂伤不起。。。留给架构师去用吧~~了解了解就拉倒了~~

不过最近找工作~~应付面试之类的还是可以白话白话的~又不过~往往面试官都不想听工厂模式。。。（工厂君：~~~~(>_<)~~~~ 呜呜~不带这么鄙视模式的~我还是有威力加强版的~）