设计模式学习总结：抽象工厂（Abstract Factory）

意图

提供一个创建一系列相关或者相互依赖对象的接口，而无需指定它们具体的类。

适用性

1. 一个系统要独立于它的产品的创建、组合和表示时。
2. 一个系统要由多个产品系列中的一个来配置时。
3. 当你要强调一系列相关的产品对象的设计以便进行联合使用时。
4. 当你提供一个产品类库，而只是想显示它们的接口而不是实现时。

结构

优缺点

优点

1>它分离了具体的类。因为一个工厂封装了创建产品对象的责任和过程，它将客户和类的实现分离。客户通过它们的抽象接口操纵实例。产品的类名也在具体工厂的实现中被分离，它们不出现在客户代码中。
2>当有多个产品系列时，它易于交换产品系列。因为一个抽象工厂创建了一个完整的产品系列，我们只需改变具体的工厂即可使用不同的产品系列。
3>它有利于产品的一致性。当一个系列中的产品对象被设计成一起工作时，一个应用一次只能使用一系列的产品，这一点很重要。

缺点

难以支持新种类的产品。抽象工厂的接口确定了可以被创建的产品集合，要支持新种类的产品就必须为所有工厂都新增一个接口。

实现

1>将工厂作为单件。一个应用中一般每个产品系列只需要一个抽象工厂，因此工厂最好实现为一个singleton。
2>创建产品。Abstract Factory仅声明一个创建产品的接口，真正创建产品是由ConcreteProduct子类来实现的。最通常的方法是为每一个产品定义一个工厂方法（Factory Method），一个具体的工厂将为每个产品重定义该工厂方法以指定产品。
3>定义可扩展的工厂。我们知道增加一种新的产品时，我们需要改变Abstract Factory的接口以及所有与它相关的类。一个更灵活但不安全的设计是给创建对象的操作增加一个参数，该参数指定了将被创建的对象的种类。但是仅有在所有对象都有相同的抽象基类，或者当产品对象可以被请求它们的客户安全的转换为正确类型时，你才能使用它。但是这种做法仍然具有一个问题，即客户不能区分或对一个产品的类别进行安全的假定，虽然客户可以进行向下的类型转换（比如用dynamic_cast），但是这并不总是安全的。

示例

相关模式

Factory Method（工厂方法）:Abstract Factory通常用工厂方法来实现。
singleton:一个具体的工厂通常是一个单件。