Aliases: Kit
** Intent**
―Provide an interface for creating families of related ordependent objects without specifying their concreteclasses.‖ （提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类 – 客户端不必指定产品的具体类型，创建多个产品族中的产品对象）
** Motivation**
为保证视感风格标准间的可移植性，应用不应该为一个特定的视感外观硬编码它的窗口组件。在整个应用中实例化特定视感风格的窗口组件类将使得以后很难改变视感风格。
对产品族，如果采用工厂方法模式，则需要使用多个独立的工厂等级结构来对付这多个产品等级结构。是否可以使用同一个工厂等级结构来对付这些相同或者及其相似的产品等级结构呢？
1）什么情况下使用抽象工厂模式？ [GOF]
一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节，这对于 所有形态的工厂模式都很重要；
该系统的产品有多于一个的产品族，而系统只消费其中某一族的产品；（原 始用意）
同属于同一产品族的产品是在一起使用的，这一约束条件必须在系统的设计 中体现出来；
系统提供一个产品类的库，所有的产品以同样的接口
一个系统要独立于它的产品的创建、组合和表示时。
一个系统要由多个产品系列中的一个来配臵时。
当你要强调一系列相关的产品对象的设计以便进行联合使用时。
当你提供一个产品类库，而只想显示它们的接口而不是实现时。
1）优点
分离了具体的类。抽象工厂模式中一个工厂封装创建产品对象的责任和过程。它将客户和类的实现分离，客户通过抽象接口操纵实例，产品的类名也在具体工厂的实现中被分离，它们不出现在客户代码中。
易于交换产品系列。一个具体工厂类在一个应用中仅出现一次——即在它初始化的时候。这使得改变一个应用的具体工厂变得很容易。它只需改变具体的工厂即可使用不同的产品配臵，这是因为一个抽象工厂创建了一个完整的产品系列，所以整个产品系列会立刻改变。
有利于产品的一致性。当一个系列的产品对象被设计成一起工作时，一个应用一次只能使用同一个系列中的对象
2）缺点
难以增加新产品的等级结构：需要修改所有的工厂角色，没有很好支持"开放－封闭"原则。
