【设计模式】(二)工厂模式

上文我们介绍了《【设计模式】(一)单例模式》

工厂模式分3类：简单工厂，工厂方法，抽象工厂。
本文从核心本质、分析、模式对比、应用场景、图形分析等方面做对比分析。

一. 工厂模式

实现了创建者和调用者的分离

二. 核心本质

实例化对象，用工厂方法代替new操作

将选择实现类，创建对象统一管理和控制。从而将调用者跟实现类解耦。

三. 详细分类

1. 简单工厂/静态工厂

工厂类一般是使用静态方法。通过接收的参数的不同来返回不同的对象实例。

用来生产同一等级结构中的任意产品。

对于增加新的产品，需要修改已有代码

不符合设计原则，但实际使用最多

2. 工厂方法

用来生产同一等级结构的固定产品（支持增加任意产品）

为了避免简单工厂的缺点，不完全满足OCP。

和简单工厂最大的区别：

       简单工厂只有一个工厂类（对一个项目或者一个独立模块而言）

       工厂方法模式有一组实现了相同接口的工厂类。

3. 抽象工厂

用来生产不同产品族的全部产品

不可以增加新产品，支持增加产品族

是工厂方法的升级版本，适用于：多个业务品种，业务分类时

四. 简单工厂模式PK工厂方法

1. 结构复杂度

简单工厂：结构简单，只需要一个工厂类。

工厂方法：工厂类随着产品类个数的增加而增加。从而增加结构复杂度

2. 代码复杂度（与结构复杂度，恰好相反）

简单工厂：工厂类随着产品类的增加而增加很多方法/代码，故较复杂

工厂方法：每个具体工厂类只完成单一任务，代码简洁。

3. 客户端编程难度

简单工厂：较简单。工厂类是个静态类，在客户端无需实例化。

工厂方法：较复杂。工厂类结构中引入了接口从而满足了OCP，但客户端编码中需要对工厂类进行实例化。

4. 管理上的难度

 1) 扩展性

简单工厂：不满足OCP，需要通过修改工厂类代码，来实现扩展性。不拘泥于理论，较常用。

工厂方法：完全满足OCP，即具有良好的扩展性。

 2) 维护性

简单工厂：多个产品类需要修改时，只需要修改唯一的工厂类

工厂方法：若某个具体产品类需要需改，则需要修改对应的工厂类。当同事需要修改多个产品类时，则对多个工厂类的修改变得非常复杂。

根据设计理论建议：工厂方法。但，设计上我们一般用简单工厂。

五. 应用场景

 1. 工厂模式

JDK中Calendar的getInstance方法

JDBC中Connection对象的获取

Hibernate中SessionFactory创建Session

Spring中IOC容器创建管理bean对象

XML解析时，DocumentBuilderFactory创建解析器对象

反射中Class对象的newInstance()

六. 图形对比

1. 简单工厂

2. 工厂方法

3. 抽象工厂