工厂方法模式

• 工厂方法模式
  • 1 模式的定义
  • 2 模式的结构
    • 2.1 结构图
    • 2.2 参与者
  • 3 模式分析
    • 3.1 优点
    • 3.2 缺点
  • 4 适用环境
  • 5 实现方式
  • 6 代码实现
  • 参考

本文介绍工厂方法模式定义、结构、特点、适用场景、代码实现。

工厂方法模式

1 模式的定义

工厂方法模式(Factory Method Pattern)又称为工厂模式，也叫虚拟构造器(Virtual Constructor)模式或者多态工厂(Polymorphic Factory)模式，它属于类创建型模式。在工厂方法模式中，工厂父类负责定义创建产品对象的公共接口，而工厂子类则负责生成具体的产品对象，这样做的目的是将产品类的实例化操作延迟到工厂子类中完成，即通过工厂子类来确定究竟应该实例化哪一个具体产品类。

2 模式的结构

2.1 结构图

2.2 参与者

1. 产品（Product）将会对接口进行声明。对于所有由创建者及其子类构建的对象，这些接口都是通用的。
2. 具体产品（Concrete Products）是产品接口的不同实现。
3. 创建者（Creator）类声明返回产品对象的工厂方法。该方法的返回对象类型必须与产品接口相匹配。 你可以将工厂方法声明为抽象方法，强制要求每个子类以不同方式实现该方法。或者，你也可以在基础工厂方法中返回默认产品类型。注意，尽管它的名字是创建者，但他最主要的职责并不是创建产品。一般来说，创建者类包含一些与产品相关的核心业务逻辑。工厂方法将这些逻辑处理从具体产品类中分离出来。打个比方，大型软件开发公司拥有程序员培训部门。但是，这些公司的主要工作还是编写代码，而非生产程序员。
4. 具体创建者（Concrete Creators） 将会重写基础工厂方法，使其返回不同类型的产品。注意，并不一定每次调用工厂方法都会创建新的实例。

3 模式分析

3.1 优点

• 你可以避免创建者和具体产品之间的紧密耦合。
• 单一职责原则。你可以将产品创建代码放在程序的单一位置，从而使得代码更容易维护。
• 开闭原则。无需更改现有客户端代码，你就可以在程序中引入新的产品类型。

3.2 缺点

应用工厂方法模式需要引入许多新的子类，代码可能会因此变得更复杂。最好的情况是将该模式引入创建者类的现有层次结构中。

4 适用环境

• 一个类不知道它所需要的对象的类：在工厂方法模式中，客户端不需要知道具体产品类的类名，只需要知道所对应的工厂即可，具体的产品对象由具体工厂类创建；客户端需要知道创建具体产品的工厂类。
• 一个类通过其子类来指定创建哪个对象：在工厂方法模式中，对于抽象工厂类只需要提供一个创建产品的接口，而由其子类来确定具体要创建的对象，利用面向对象的多态性和里氏代换原则，在程序运行时，子类对象将覆盖父类对象，从而使得系统更容易扩展。
• 将创建对象的任务委托给多个工厂子类中的某一个，客户端在使用时可以无须关心是哪一个工厂子类创建产品子类，需要时再动态指定，可将具体工厂类的类名存储在配置文件或数据库中。

5 实现方式

1. 让所有产品都遵循同一接口。该接口必须声明对所有产品都有意义的方法。
2. 在创建类中添加一个空的工厂方法。该方法的返回类型必须遵循通用的产品接口。
3. 在创建者代码中找到对于产品构造函数的所有引用。将它们依次替换为对于工厂方法的调用，同时将创建产品的代码移入工厂方法。你可能需要在工厂方法中添加临时参数来控制返回的产品类型。工厂方法的代码看上去可能非常糟糕。其中可能会有复杂的switch 分支 运算符，用于选择各种需要实例化的产品类。但是不要担心，我们很快就会修复这个问题。
4. 现在，为工厂方法中的每种产品编写一个创建者子类，然后在子类中重写工厂方法，并将基本方法中的相关创建代码移动到工厂方法中。
5. 如果应用中的产品类型太多，那么为每个产品创建子类并无太大必要，这时你也可以在子类中复用基类中的控制参数。
6. 如果代码经过上述移动后，基础工厂方法中已经没有任何代码，你可以将其转变为抽象类。如果基础工厂方法中还有其他语句，你可以将其设置为该方法的默认行为。

6 代码实现

https://github.com/august295/DesignPatternCode

参考

[1] https://refactoringguru.cn/design-patterns/factory-method

[2] https://design-patterns.readthedocs.io/zh_CN/latest/creational_patterns/factory_method.html