通过我这次在 Java 预科班的“回炉重造”（不得不说这两个月时间的预科内容是真的十足！），勾起了我对设计模式的一些兴趣及思考，紧接着就安排自己记录一下自己曾经模糊的一些概念和知识。
结合课程和一些书籍资料，本文将着重讲述工厂方法模式。
亦称： 虚拟构造函数、 Virtual Constructor、 Factory Method
工厂方法模式是一种创建型设计模式， 其在父类中提供一个创建对象的方法， 允许子类决定实例化对象的类型。
问题
假设我们正在开发一哥物流管理的应用。最初版本只能处理卡车运输，因此大部分代码都在位于名为卡车的类中。
一段时间后，这款应用变得极受欢迎，每天都能收到十几次来自海运公司的请求，希望应用能够支持海上物流的功能。
如果代码其余部分与现有类已经存在耦合关系， 那么向程序中添加新类其实并没有那么容易。
虽然对业务来说是一个好消息，但是代码问题该如何处理呢？目前，大部分代码都与卡车类相关。在程序中添加
类需要修改全部代码。还要考虑到以后需要在应用中支持另外一种运输方式（如空运），很可能需要再次对这些代码进行大幅度的调整。
最后，我们将不得不编写繁复的代码，根据不同的运输对象类，在应用中进行不同的处理。
解决方案
工厂方法模式建议使用特殊的工厂方法代替对于对象构造函数的直接调用（即使用new运算符）。不用担心的是对象仍然可以通过new运算符创建，只是该运算符改在工厂方法中调用罢了。工厂方法返回的对象通常被称作“产品”。
子类可以修改工厂方法返回的对象类型。
乍看之下，这种更改可能毫无意义：我们只是改变了程序中调用构造函数的位置而已。但是，仔细想一下，现在我们可以在子类中重写工厂方法，从而改变其创建产品的类型。
但有一点需要注意：仅当这些产品具有共同的基类或者接口时，子类才能返回不同类型的产品，同时基类中的工厂方法还应将其返回类型声明为这一共有接口。
所有产品都必须使用同一接口。
举例来说，卡车Truck和邮轮Ship类都必须实现运输Transport接口，该接口声明了一个名为deliver交付的方法。每个类都以不同的方式实现该方法：卡车走陆路交付货物，邮轮走海路交付货物。陆路运输RoadLogistics类中的工厂方法返回卡车对象，而海路运输SeaLogistics类则返回邮轮对象。
只要产品类实现一个共同的接口， 你就可以将其对象传递给客户代码， 而无需提供额外数据。
调用工厂方法的代码（通常被称为客户端代码）无需了解不同子类返回实际对象之间的差别。客户端将所有产品视为抽象的运输。客户端知道所有运输对象都提供交付方法，但是并不关心其具体的实现方式。
结构体
-
产品（Product） 将会对接口进行声明。对于所有由创建者及其子类构建的对象，这些接口都是通用的。
-
具体产品 （Concrete Products）是产品接口的不同实现。
-
创建者（Creator）类声明返回产品对象的工厂方法。该方法的返回对象类型必须与产品接口相匹配。
-
具体创建者（Concrete Creators）将会重写基础工厂方法，使其返回不同类型的产品。
注意， 并不一定每次调用工厂方法都会创建新的实例。 工厂方法也可以返回缓存、 对象池或其他来源的已有对象。
适用性
🤨 当我们在编写代码的过程中，如果无法预知对象确切类别及其依赖关系时，可使用工厂方法。
工厂方法将创建产品的代码与实际使用产品的代码分离，从而能在不影响其他代码的情况下扩展产品创建部分代码。
例如，如果需要向应用中添加一种新产品，只需要开发新的创建者子类，然后重写其工厂方法即可。
🤨 如果希望用户能扩展你软件库或框架的内部组件，可使用工厂方法。
继承可能是扩展软件库或框架默认行为的最简单方法。但是当使用子类替代标准组件时，框架如何辨识出该子类？
解决方案是将各框架中构造组件的代码集中到单个工厂方法中，并在继承该组件之外允许任何人对该方法进行重写。
让我们看看具体是怎么实现的。假设使用开源 UI 框架编写自己的应用。希望在应用中使用圆形按钮，但是原框架仅支持矩形按钮。那么我们可以使用
圆形按钮RoundButton子类来继承标准的按钮Button类。但是我们需要告诉UI 框架 UIFramework类使用新的子类按钮代替默认的矩形按钮。
为了实现这个功能，我们可以根据基础框架类开发子类圆形按钮UI UIWithRoundButton，并且重写其createButton创建按钮的方法。父类中的该方法返回按钮对象，而我们开发的子类返回圆形按钮对象。这样一来，我们就可以使用圆形按钮 UI类来代替UI框架类了。
🤨 如果希望复用现有对象来节省系统资源， 而不是每次都重新创建对象， 可使用工厂方法。
在处理大型资源密集型对象（比如数据库连接、文件系统和网络资源）时，会经常碰到这种资源需求。
让我们思考复用现有对象的方法：
- 首先，需要创建存储空间来存放所有已经创建的对象。
- 当有人请求一个对象时，程序将在对象池中搜索可用对象。
- 然后将其返回给客户端代码。
- 如果没有可用对象，程序则创建一个新对象（并将其添加到对象池中）。
这些代码可不少！而且它们必须位于同一处，这样才能确保重复代码不会污染程序。
可能最显而易见，也是最方便的方式，就是将这些代码放置在我们试图重用的对象类的构造函数中。但是从定义上来讲，构造函数始终返回的是新对象，其无法返回现有实例。
因此，我们需要有一个既能够创建新对象，又可以重用现有对象的普通方法。这听上去和工厂方法非常相像。
如何实施
-
让所有产品都遵循同一接口。该接口必须声明对所有产品都有意义的方法。
-
在创建类中添加一个空的工厂方法。该方法的返回类型必须遵循通用的产品接口。
-
在创建者代码中找到对于产品构造函数的所有引用。将它们依次替换为对于工厂方法的调用，同时将创建产品的代码移入工厂方法。可能需要在工厂方法中添加临时参数来控制返回的产品类型。
-
为工厂方法中的每种产品编写一个创建者子类，然后在子类中重写工厂方法，并将基本方法中的相关创建代码移动到工厂方法中。
-
如果应用中的产品类型太多，那么为每个产品创建子类并无太大必要，这时也可以在子类中复用基类中的控制参数。
-
如果代码经过上述移动后，基础工厂方法中已经没有任何代码，可以将其转变为抽象类。如果基础工厂方法中还有其他语句，可以将其设置为该方法的默认行为。
例如，设想有以下一些层次结构的类。基类
邮件及其子类航空邮件和陆路邮件；运输及其子类飞机,卡车和火车。航空邮件仅使用飞机对象，而陆路邮件则会同时使用卡车和火车对象。可以编写一个新的子类 （例如火车邮件）来处理这两种情况，但是还有其他可选的方案。客户端代码可以给陆路邮件类传递一个参数，用于控制其希望获得的产品。
⚖️ 利 弊
✅ 可以避免创建者和具体产品之间的紧密耦合。
✅ 单一职责原则。可以将产品创建代码放在程序的单一位置，从而使得代码更容易维护。
❎ 应用工厂方法模式需要引入许多新的子类，代码可能会因此变得更复杂。最好的情况是将该模式引入创建者类的现有层次结构中。
