工厂方法模式
相关信息
设计模式-创建型模式-工厂方法模式
意图
在父类中提供了一个创建对象的方法，允许子类决定实例化对象的类型
动机
针对简单工厂模式的缺点，使用工厂方法模式就可以完美的解决，完全遵循开闭原则。
定义
工厂方法模式是一种创建型设计模式， 其在父类中提供一个创建对象的方法， 允许子类决定实例化对象的类型。
结构
工厂方法模式的主要角色：
- 抽象工厂（Abstract Factory）：提供了创建产品的接口，调用者通过它访问具体工厂的工厂方法来创建产品。
- 具体工厂（ConcreteFactory）：主要是实现抽象工厂中的抽象方法，完成具体产品的创建。
- 抽象产品（Product）：定义了产品的规范，描述了产品的主要特性和功能。
- 具体产品（ConcreteProduct）：实现了抽象产品角色所定义的接口，由具体工厂来创建，它同具体工厂之间一一对应。
UML
案例
要增加产品类时也要相应地增加工厂类，不需要修改工厂类的代码了，这样就解决了简单工厂模式的缺点。
工厂方法模式是简单工厂模式的进一步抽象。由于使用了多态性，工厂方法模式保持了简单工厂模式的优点，而且克服了它的缺点。
优缺点
优点：
- 减少耦合 你可以避免创建者和具体产品之间的紧密耦合。
- 单一职责原则。 你可以将产品创建代码放在程序的单一位置， 从而使得代码更容易维护。
- 开闭原则。 无需更改现有客户端代码， 你就可以在程序中引入新的产品类型。
缺点：
- 引入更多的子类，代码会复杂 应用工厂方法模式需要引入许多新的子类， 代码可能会因此变得更复杂。 最好的情况是将该模式引入创建者类的现有层次结构中。
应用场景
当你在编写代码的过程中， 如果无法预知对象确切类别及其依赖关系时， 可使用工厂方法。
工厂方法将创建产品的代码与实际使用产品的代码分离， 从而能在不影响其他代码的情况下扩展产品创建部分代码。
例如， 如果需要向应用中添加一种新产品， 你只需要开发新的创建者子类， 然后重写其工厂方法即可。
如果你希望用户能扩展你软件库或框架的内部组件， 可使用工厂方法。
继承可能是扩展软件库或框架默认行为的最简单方法。 但是当你使用子类替代标准组件时， 框架如何辨识出该子类？
解决方案是将各框架中构造组件的代码集中到单个工厂方法中， 并在继承该组件之外允许任何人对该方法进行重写。
如果你希望复用现有对象来节省系统资源， 而不是每次都重新创建对象， 可使用工厂方法。
在处理大型资源密集型对象 （比如数据库连接、 文件系统和网络资源） 时， 你会经常碰到这种资源需求。
让我们思考复用现有对象的方法：
- 首先， 你需要创建存储空间来存放所有已经创建的对象。
- 当他人请求一个对象时， 程序将在对象池中搜索可用对象。
- … 然后将其返回给客户端代码。
- 如果没有可用对象， 程序则创建一个新对象 （并将其添加到对象池中）。
这些代码可不少！ 而且它们必须位于同一处， 这样才能确保重复代码不会污染程序。
可能最显而易见， 也是最方便的方式， 就是将这些代码放置在我们试图重用的对象类的构造函数中。 但是从定义上来讲， 构造函数始终返回的是新对象， 其无法返回现有实例。
因此， 你需要有一个既能够创建新对象， 又可以重用现有对象的普通方法。 这听上去和工厂方法非常相像。