1. 意图
提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
2. 结构
此模式的结构如下图所示。
3. 参与者
- AbstractFactory
-- 声明一个创建抽象产品对象的操作接口。 - ConcreteFactory
-- 实现创建具体产品对象的操作。 - AbstractProduct
-- 为一类产品对象声明一个接口。 - ConcreteProduct
-- 定义一个将被相应的具体工厂创建的产品对象。
-- 实现AbstractProduct接口。 - Client
-- 仅使用由AbstractFactory和AbstractProduct类声明的接口。
4. 协作
- 通常在运行时刻创建一个ConcreteFactory类的实例。这一具体的工厂创建具有特定实现的产品对象。为创建不同的产品对象，客户应使用不同的具体工厂。
- AbstractFactory将产品对象的创建延迟到它的ConcreteFactory子类。
5. 效果
AbstractFactory模式有下面的一些优点和缺点：
1) 它分离了具体的类 Abstract Factory模式帮助你控制一个应用创建的对象的类。因为一个工厂封装创建产品对象的责任和过程，它将客户与类的实现分离。客户通过它们的抽象接口操纵实例。产品的类名也在具体工厂的实现中被分离；它们不出现在客户代码中。
2) 它使得易于交换产品系列 一个具体工厂类在一个应用中仅出现一次--即在它初始化的时候。这使得改变一个应用的具体工厂变得很容易。它只需改变具体的工厂即可使用不同的产品配置，这是因为一个抽象工厂创建了一个完整的产品系列，所以整个产品系列会立刻改变。
3) 它有利于产品的一致性 当一个系列中的产品对象被设计成一起工作时，一个应用一次只能使用同一个系列中的对象，这一点很重要。而AbstractFactory很容易实现这一点。
4) 难以支持新种类的产品 难以扩展抽象工厂以生产新种类的产品。这是因为AbstractFactory接口确定了可以被创建的产品集合。支持新种类的产品就需要扩展该工厂接口，这将涉及AbstractFactory类及其所有子类的改变。
【摘自《设计模式 可复用面向对象软件的基础》机械工业出版社】