意图：
提供创建一系列相关或者相互依赖对象的接口而无需指定它们具体的类。要创建的一系列类
或者接口应该是协同工作的，创建的是同一“种类”（系列）的一套内容，同一时刻只能存在
一种系列。
通俗的例子：
设想一个汽车零件生产厂，我们可以将这个概念理解为一个抽象工厂，作为一个汽车零件生
产厂，那么它可以生产很多种零件，这就对应一系列的生成另外的对象的方法，而一个具体
的汽车零件生成厂生产的零件都是配套的（假设它只为一种型号的汽车生成零件）。
参与者：
Client：就是顾客或者客户，例子中就是购买零件的顾客
AbstractFactory：抽象工厂，一个概念，定义一些抽象的接口，例子中就是汽车零件生成厂
这个概念
ConcreteFactory：具体工厂，就是真正生成产品的工厂，例子中就是具体的某个生成汽车零
件的生成厂
AbstractProduct：抽象产品，要由工厂生成的对象，例子中就是构成汽车需要的零件，例如
车门、轮胎、底盘、发动机
ConcreteProduct：具体的产品，例子中就是具体的某种型号的零件，例如用于捷达的车门、
轮胎、底盘以及发动机
适用性：
1、一个系统要独立于它的产品的创建、组合和表示。
2、一个系统要由多个产品系列中的一个来进行配置。
3、当你要强调一系列相关产品对象的设计以便进行联合使用。
4、当你提供一个产品库而只想显示它们的接口而不是实现。
优点：
1、控制一个应用创建的对象的类，将客户与类的实现分离（生成对象实例的客户可能都不
知道生成的对象实例的真实类名），客户只能通过提供的接口（包括抽象工厂和抽象产品）
对对象进行操作。
2、改变产品系列更容易，因为设置或者选择产品系列的代码只出现一次（即生成具体工厂
实例的时候），当我们改变具体的工厂实例的时候整个产品系列也随之改变。
3、有利于产品一致性，由于工厂的限制，我们只能生成同一系列的产品。
缺点：
1、难以支持新种类的产品，因为工厂已经定义了可以被创建的产品的种类，如果要增加新
的产品意味着可能需要修改工厂的所有具体子类并定义各自的具体产品。这个缺点有以下几
种方法进行解决：在抽象工厂中增加产品的时候定义的方法不是抽象方法，使用返回null或
者一个缺省的产品实例而且原则上不属于某个特定的产品系列，这个解决方法的缺点是破坏
了整体的一致性；定义产品生成的方法是只定义一个根据参数生成指定产品的方法，这样可
以动态的增加产品种类，但是这种方法不是很安全，代码的问题可能到运行时才能显现（参
数值错误，但是可能没有编译错误），另外一个问题是所有的产品需要定义一个公共的抽象
接口并且该方法返回的也是该公共接口，但是这个又接着引发一个问题：公共接口要么提供
的方法过多，要么需要客户得到产品实例后向下造型（downcast，即将一个父类的对象造型
为其具体子类对象），而向下造型操作由于可能失败也是不安全的。
2、由于一般情况下工厂通过工厂方法来创建产品，因此每个具体的工厂都要全部重写那些
工厂方法，即使产品系列直接的差异可能很小。
技巧：
1、由于工厂通常有一个就可以，因此具体工厂子类一般都实现为一个Singleton。
2、抽象工厂创建产品的方法定义为工厂方法。
3、如果有多个可能的产品系列，具体的工厂也可以使用原型模式，具体工厂使用产品系列中
每一个产品的原型进行实例化并且通过复制它的原型来创建新的产品。
典型Java案例：
Jive论坛：
ForumFactory就是AbstractFactory，它本身通过工厂方法创建产品（例如createColumn、
createThread、createMessage、createQuery都是使用工厂方法）而且自身实现为一个
Singleton。 |
|
