意图
把相关的零件组合成产品，侧重点在于零件的组合而不是零件的实现
提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
新增具体工厂如探囊取物，但是新增零件却难上加难
用意：给客户端提供一个接口，可以创建多个产品族中的产品对象
条件：
1. 系统中有多个产品族，而系统一次只能消费其中一族产品
2. 同属于同一个产品族的产品一起使用
适用性
在以下情况可以使用Abstract Factory模式
1. 一个系统要独立于它的产品的创建、组合和表示时。
2. 一个系统要由多个产品系列中的一个来配置时
3. 当你要强调一系列相关的产品对象的设计以便进行联合使用时
4. 当你提供一个产品类库，而只想显示它们的接口而不是实现时。
5. 一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节，这对于所有类型的工厂模式都是重要的。
6. 系统中有多于一个的产品族，而每次只使用其中某一产品族。
7. 属于同一个产品族的产品将在一起使用，这一约束必须在系统的设计中体现出来。
8. 系统提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于具体实现。
结构
参与者
AbstractFactory
- 声明一个创建抽象产品对象的操作接口
- 核心，与应用无关，是具体工厂必须实现的对象
ConcreteFactory
- 实现创建具体产品对象的操作
- 含有具体业务逻辑相关的代码，创建具体的产品
AbstractProduct
- 为一类产品对象声明一个接口
- 具体产品需要实现的类
ConcreteProduct
- 定义一个将被相应的具体工厂创建的产品对象
- 实现AbstractProduct
- 具体工厂所创建的对象就是该角色的实例
Client
1.仅使用由AbstractFactory和AbstractProduct类声明的接口。
代码
AbstractFactory
public abstract class AbstractFactory {
public abstract AbstractProductCarBC getBCCar();
public abstract AbstractProductCarBM getBMCar();
}
ConcreteFactory
public class ConcreteFactoryPC extends AbstractFactory{
public AbstractProductCarBC getBCCar() {
return new ConcreteProductCarBCPC();
}
public AbstractProductCarBM getBMCar() {
return new ConcreteProductCarBMPC();
}
}
public class ConcreteFactoryPT extends AbstractFactory{
public AbstractProductCarBC getBCCar() {
return new ConcreteProductCarBCPT();
}
public AbstractProductCarBM getBMCar() {
return new ConcreteProductCarBMPT();
}
}
AbstractProduct
public abstract class AbstractProductCarBC {
public abstract void driver();
}
public abstract class AbstractProductCarBM {
public abstract void driver();
}
ConcreteProduct
public class ConcreteProductCarBCPC extends AbstractProductCarBC{
public void driver() {
System.out.println("我是奔驰中的跑车系列！");
}
}
public class ConcreteProductCarBCPT extends AbstractProductCarBC{
public void driver() {
System.out.println("我是奔驰中的普通车系列！");
}
}
public class ConcreteProductCarBMPC extends AbstractProductCarBM{
public void driver() {
System.out.println("我是宝马中的跑车系列！");
}
}
public class ConcreteProductCarBMPT extends AbstractProductCarBM{
public void driver() {
System.out.println("我是宝马中的普通车系列！");
}
}
Client
public class Client {
public static void main(String[] args) {
AbstractFactory concreteFactoryPC = new ConcreteFactoryPC();
concreteFactoryPC.getBCCar().driver();
concreteFactoryPC.getBMCar().driver();
AbstractFactory concreteFactoryPM = new ConcreteFactoryPT();
concreteFactoryPM.getBCCar().driver();
concreteFactoryPM.getBMCar().driver();
}
}
协作
- 通常在运行时刻创建一个ConcreteFactory类的实例。这一具体的工厂创建具有特定实现的产品对象。为创建不同的产品对象，客户应使用不同的具体工厂。
- AbstractFactory将产品对象的创建延迟到它的ConcreteFactory子类。
效果
它分离了具体的类
AbstractFactory模式帮助你控制一个应用创建的对象的类。因为一个工厂封装创建产品对象的责任和过程，它将客户与类的实现分离。客户通过它们的抽象接口操纵实例。产品的类名也在具体工厂的实现中被分离；它们不出现在客户代码中。
它使得易于交换产品系列
一个具体工厂类在一个应用中仅出现一次，即在它初始化的时候。这使得改变一个应用的具体工厂变得很容易。它只需要改变具体的工厂即可使用不同的产品配置，这是因为一个抽象工厂创建了一个完整的产品系列，所以整个产品系列会立刻改变。
它有利于产品的一致性
当一个系列中的产品对象被设计成一起工作时，一个应用一次只能使用同一个系列中的对象，这一点很重要。而AbstractFactory很容易实现这一点。
难以支持新种类的产品
难以扩展抽象工厂以生产新种类的产品。这是因为AbstractFactory接口确定了可以被创建的产品集合。支持新种类的产品就需要扩展该工厂接口，这将涉及到AbstractFactory类及其所有子类的改变。
优点
- 抽象工厂模式隔离了具体类的生产，使得客户并不需要知道什么被创建
- 当一个产品族中的多个对象被设计成一起工作时，它能保证客户端始终只使用同一个产品族中的对象
- 增加新的具体工厂和产品族很方便，无须修改已有系统，符合“开闭原则”
缺点
增加新的产品等级结构很复杂，需要修改抽象工厂和所有的具体工厂类，对“开闭原则”的支持呈现倾斜性。
实现
将工厂作为单件
一个应用中一般每个产品系列只需要一个ConcreteFactory的实例。因此工厂通常最好实现为一个Singleton。
创建产品
AbstractFactory仅声明一个创建产品的接口，真正创建产品是由ConcreteProduct子类实现的。最通常的一个办法是为每一个产品定义一个工厂方法（Factory Method）。一个具体的工厂将为每个产品重定义该工厂方法以指定产品。虽然这样的而实现很简单，但它却要求每个产品系列都要有一个新的具体工厂子类，即使这些产品系列的差别很小。
如果有多个可能的产品系列，具体工厂也可以使用Prototype模式来实现。具体工厂使用产品系列中每一个产品的原型实例来初始化，且它通过复制它的原型来创建新的产品。在基于原型的方法中，使得不是每个新的产品系列都需要一个新的具体工厂类。
定义可扩展的工厂
AbstractFactory通常为每一种它可以生产的产品定义一个操作。产品的种类被编码在操作构型中。增加一种新的产品要求改变AbstractFactory的接口以及所有与它相关的类。一个更灵活但不太安全的设计是给创建对象的操作增加一个参数。该参数指定了将被创建的对象的种类。它可以是一个类标识符、一个整数、一个字符串，或者其他任何可以标识这种产品的东西。实际上使用这种方法，AbstractFactory只需要一个Make操作和一个指示要创建对象的种类的参数。
C++这样的静态类型语言与相比，这一变化更容易用在动态类型语言中。仅当所有对象都有相同的抽象基类，或者当产品对象可以被请求它们的客户安全的强制转换成正确类型时，你才能够在C++中使用它。 Factory Method的实现部分说明了怎样在C++中实现这样的参数化操作。
该方法即使不需要类型强制转换，但仍有一个本质的问题：所有的产品将返回类型所给定的相同的抽象接口返回给客户。客户将不能区分或对一个产品的类别进行安全的假定。如
果一个客户需要进行与特定子类相关的操作，而这些操作却不能通过抽象接口得到。虽然客
户可以实施一个向下类型转换（downcase）（例如在C + +中用dynamic_case），但这并不总是可行或安全的，因为向下类型转换可能会失败。这是一个典型的高度灵活和可扩展接口的权衡折衷。
经典例子
实现产品族的模型
相关模式
Builder Pattern
抽象工厂是接口规定的抽象零件，产生构造复杂对象的实例；构造模式则是循序渐进构建大规模对象实例
Factory Method Pattern
抽象工厂模式中产生产品和零件的部分可能会变成工厂方法模式。
AbstractFactory类通常用工厂方法（Factory Method）实现，但它们也可以用Prototype实现。
Composite Pattern
以抽象工厂模式所产生的产品可能是组合模式
Singleton Pattern
抽象工厂模式具体的工厂可能是单例模式
一个具体的工厂通常是一个单件（Singleton）。
敬请期待“单列模式（Singleton Pattern、单态模式、单件模式、对象创建型模式）”
95
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
