1.0 工厂模式之工厂方法模式

1.1 工厂方法模式定义

• 定义了一个创建对象的接口，但由子类决定要实例化哪个类。工厂方法让类把实例化推迟到子类。

工厂模式是“创建型”设计模式之一。

1.2 工厂方法模式的使用场景

• 一个类不知道它所需要的对象的类：在工厂方法模式中，客户端不需要知道具体产品类的类名，只需要知道所对应的工厂即可，具体的产品对象由具体工厂类创建；客户端需要知道创建具体产品的工厂类。

• 一个类通过其子类来指定创建哪个对象：在工厂方法模式中，对于抽象工厂类只需要提供一个创建产品的接口，而由其子类来确定具体要创建的对象，利用面向对象的多态性和里氏代换原则，在程序运行时，子类对象将覆盖父类对象，从而使得系统更容易扩展。

• 将创建对象的任务委托给多个工厂子类中的某一个，客户端在使用时可以无须关心是哪一个工厂子类创建产品子类，需要时再动态指定，可将具体工厂类的类名存储在配置文件或数据库中。

1.3 工厂方法模式UML类图

工厂方法UML类图.png

角色介绍：

• Factory： 抽象工厂,为工厂方法模式的核心;
• ConcreteFactory ： 具体工厂,实现了具体的业务逻辑;
• Product： 抽象产品,是工厂方法模式所创建的产品的父类;
• ConcreteProduct： 具体产品,为实现抽象产品的某个具体产品的对象;

1.4 工厂方法模式优点：

• 在工厂方法模式中，工厂方法用来创建客户所需要的产品，同时还向客户隐藏了哪种具体产品类将被实例化这一细节，用户只需要关心所需产品对应的工厂，无须关心创建细节，甚至无须知道具体产品类的类名。

• 基于工厂角色和产品角色的多态性设计是工厂方法模式的关键。它能够使工厂可以自主确定创建何种产品对象，而如何创建这个对象的细节则完全封装在具体工厂内部。工厂方法模式之所以又被称为多态工厂模式，是因为所有的具体工厂类都具有同一抽象父类。

• 使用工厂方法模式的另一个优点是在系统中加入新产品时，无须修改抽象工厂和抽象产品提供的接口，无须修改客户端，也无须修改其他的具体工厂和具体产品，而只要添加一个具体工厂和具体产品就可以了。这样，系统的可扩展性也就变得非常好，完全符合“开闭原则”。

1.5 工厂方法模式缺点：

• 在添加新产品时，需要编写新的具体产品类，而且还要提供与之对应的具体工厂类，系统中类的个数将成对增加，在一定程度上增加了系统的复杂度，有更多的类需要编译和运行，会给系统带来一些额外的开销。

• 由于考虑到系统的可扩展性，需要引入抽象层，在客户端代码中均使用抽象层进行定义，增加了系统的抽象性和理解难度，且在实现时可能需要用到DOM、反射等技术，增加了系统的实现难度。

2.0 工厂模式之抽象工厂模式

2.1抽象工厂模式定义

• 提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。

抽象工厂允许客户使用抽象的接口来创建一组相关的产品， 而不需要知道(或关心)
实际产出的具体产品是什么。这样一来，客户就从具体的产品中被解耦。

2.2 抽象工厂模式的使用场景

• 一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节，这对于所有类型的工厂模式都是重要的。

• 系统中有多于一个的产品族，而每次只使用其中某一产品族。

• 属于同一个产品族的产品将在一起使用，这一约束必须在系统的设计中体现出来。
  系统提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于具体实现。

2.3 抽象工厂模式UML类图

抽象工厂UML.png
角色介绍：

虽然抽象工厂方法模式的类繁多，但是，主要还是分为4类。

AbstractFactory: 抽象工厂角色，它声明了一组用于创建一种产品的方法，每一个方法对应一种产品，如上述类图中的AbstractFactory中就定义了两个方法，分别创建产品A和产品B。

ConcreteFactory: 具体工厂角色，它实现了在抽象工厂中定义的创建产品的方法，生成一组具体产品，这些产品构成了一个产品种类，每一个产品都位于某个产品等级结构中，如上述类图中的ConcreteFactory1和ConcreteFactory2。

AbstractProduct: 抽象产品角色，它为每种产品声明接口，比如上述类图中的AbstractProductA和AbstractProductB。

ConcreteProduct: 具体产品角色，它定义具体工厂生产的具体产品对象，实现抽象产品接口中.声明的业务方法，如上述类图中的ConcreteProductA1、 ConcreteProductA2、 ConcreteProductB1 和ConcreteProductB2。

2.4 抽象工厂模式优点：

• 抽象工厂模式隔离了具体类的生成，使得客户并不需要知道什么被创建。由于这种隔离，更换一个具体工厂就变得相对容易。所有的具体工厂都实现了抽象工厂中定义的那些公共接口，因此只需改变具体工厂的实例，就可以在某种程度上改变整个软件系统的行为。另外，应用抽象工厂模式可以实现高内聚低耦合的设计目的，因此抽象工厂模式得到了广泛的应用。

• 当一个产品族中的多个对象被设计成一起工作时，它能够保证客户端始终只使用同一个产品族中的对象。这对一些需要根据当前环境来决定其行为的软件系统来说，是一种非常实用的设计模式。

• 增加新的具体工厂和产品族很方便，无须修改已有系统，符合“开闭原则”。

2.5 抽象工厂模式缺点：

• 在添加新的产品对象时，难以扩展抽象工厂来生产新种类的产品，这是因为在抽象工厂角色中规定了所有可能被创建的产品集合，要支持新种类的产品就意味着要对该接口进行扩展，而这将涉及到对抽象工厂角色及其所有子类的修改，显然会带来较大的不便。

• 开闭原则的倾斜性（增加新的工厂和产品族容易，增加新的产品等级结构麻烦）。

模式扩展

“开闭原则”的倾斜性

• “开闭原则”要求系统对扩展开放，对修改封闭，通过扩展达到增强其功能的目的。对于涉及多个产品族与多个产品等级结构的系统，其功能增强包括两方面：

  1. 增加产品族：对于增加新的产品族，工厂方法模式很好的支持了“开闭原则”，对于新增加的产品族，只需要对应增加一个新的具体工厂即可，对已有代码无须做任何修改。

  2. 增加新的产品等级结构：对于增加新的产品等级结构，需要修改所有的工厂角色，包括抽象工厂类，在所有的工厂类中都需要增加生产新产品的方法，不能很好地支持“开闭原则”。

抽象工厂模式的这种性质称为“开闭原则”的倾斜性，抽象工厂模式以一种倾斜的方式支持增加新的产品，它为新产品族的增加提供方便，但不能为新的产品等级结构的增加提供这样的方便。

工厂模式的退化

• 当抽象工厂模式中每一个具体工厂类只创建一个产品对象，也就是只存在一个产品等级结构时，抽象工厂模式退化成工厂方法模式；当工厂方法模式中抽象工厂与具体工厂合并，提供一个统一的工厂来创建产品对象，或将创建对象的工厂方法设计为静态方法时，工厂方法模式退化成简单工厂模式。

总结：

OO原则： 依赖抽象，不要依赖具体类。

• 所有的工厂都是用来封装对象的创建。
• 简单工厂，虽然不是真正的设计模式，但仍不失为一个简单的方法，可以将客户程序从具体类解耦。
• 工厂方法使用继承:把对象的创建委托给子类，子类实现工厂方法来创建对象。
• 抽象工厂使用对象组合:对象的创建被实现在工厂接口所暴露出来的方法中。
• 所有工厂模式都通过减少应用程序和具体类之间的依赖促进松耦合。
• 工厂方法允许类将实例化延迟到子类进行。
• 抽象工厂创建相关的对象家族，而不需要依赖它们的具体类。
• 依赖倒置原则，指导我们避免依赖具体类型，而要尽量依赖抽象。
• 工厂是很有威力的技巧，帮助我们针对抽象编程，而不要针对具体类编程。