工厂方法模式既保持了简单工厂模式的优点，又克服了他的缺点。
如不清楚简单工厂模式，可以查看上一篇《设计模式 | 简单工厂模式（二）》。
他是怎么做到的呢？
那就是:
核心的工厂角色，不再是具体的工厂。
也就是不再负责所有具体产品的创建，进一步转变为抽象角色。
他仅仅提供具体工厂子类必须实现的接口，不再关心应该实例化哪个具体的产品类，具体创建的工作的细节全部交给子类工厂去做。
简言之，从一个类包打天下（简单工厂模式），转换为兄弟姐妹一起上（工厂方法）
—01—
意图
定义一个用于创建对象的接口，让子类决定实例化哪一个类。
工厂方法模式使一个类的实例化，延时到其子类（就是在说，子类负责具体产品类的实例化）
别名：虚构造器
—02—
结构
抽象产品（Product）
产品抽象角色，工厂创建具体的对象的超类或共同接口。
具体产品（ConcreteProduct）
实现了抽象产品Product
ConcreteProduct1 和ConcreteProduct2为具体的产品。
抽象工厂Creator
工厂模式的核心，与应用程序无关，所有的工厂都需要实现抽象工厂角色。
具体工厂ConcreteCreator
实现了工厂接口的具体的Java类，用于产生具体的产品。
工厂模式相对于简单工厂模式，产品侧的结构形式不变，而对于工厂，变化很清晰明显。
不再是单一的Java类承担所有的对象创建职责，而是存在工厂的体系结构。
Creator作为创建工厂的抽象角色，提供了创建协议，也就是一个方法，约定了我们将要创建什么范畴的产品。
ConcreteCreator1和ConcreteCreator2 是具体的工厂，他们都实现Creator，针对不同的产品有不同的工厂 。
也就是说产品等级结构是什么样的，就会有一个类似结构的工厂等级结构，对应着的工厂创建对应着的产品。
就像上图中那样，两个圈中的层级结构是对称的，一 一对应的。
Creator对应Product
ConcreteCreator1对应ConcreteProduct1
ConcreteCreator2对应ConcreteProduct2
......
—02—
示例代码
还是以水果的为例，Fruit Apple Orange与简单工厂模式中一样。
此时
不再是一个水果店卖所有的水果，而是不同的水果店销售不同的水果。
所以对应水果这种产品的等级结构，也有对应的工厂等级结构。
Factory以及 AppleFactory和 OrangeFactory
Fruit Apple 和Orange与简单工厂中的代码相同
package simpleFactory;public interface Fruit {String description();}
package simpleFactory;public class Apple implements Fruit {@Overridepublic String description() {return "apple";}}
package simpleFactory;public class Orange implements Fruit {@Overridepublic String description() {return "Orange";}}
package factory;public interface Factory {Fruit create();}
package factory;public class AppleFactory implements Factory {@Overridepublic Fruit create() {return new Apple();}}
package factory;public class OrangeFactory implements Factory {@Overridepublic Fruit create() {return new Orange();}}
测试代码
工厂方法模式的特点就是平行的等级结构 ，也就是工厂与产品有相对应的层级结构
而不是像简单工厂模式中那样，一个全能类包揽所有创建逻辑
—03—
对比
工厂方法模式，不再将逻辑都集中在一个具体的工厂类上，而是借助于抽象的工厂角色Creator。
他是一个抽象角色，所有的工厂创建行为分布于他的实现类上，是简单工厂模式的进一步抽象。
对于工厂模式来说
如果省略抽象角色Creator，也就好像成了一个或者多个的简单工厂模式。
每个工厂类似一个简单工厂模式，所以某种程度上说，简单工厂模式是工厂方法模式的一个简化形式或者说特例形式。
工厂方法模式构造了一个创建对象的工厂框架，与产品等级结构对应的工厂等级结构不就是相等于一个创建框架嘛。
将由不同的子类工厂来具体化对象的创建。
工厂方法模式还有一个名字叫做多态性工厂模式，因为具体的工厂都有共同的接口或者共同的抽象父类，具体产品对象由具体的工厂子类创建。
创建一个Creator引用指向实际的Creator子类实例，实际创建的对象根据工厂的多态性产生。
如果系统需要加入一个新的产品时，只需要加入一个新的产品类以及对应的工厂类即可，而不需要修改已有的抽象工厂角色。
也没必要修改其他的具体的工厂角色，更没必要修改客户端的代码，所以满足了开闭原则。
而且 ， 每个工厂生产一种对应的产品，也符合单一职责原则 。
在实践中随着业务模式的深入变得复杂
如果有多个简单工厂模式，如果他们在某些方面有共性，也是可以考虑将多个简单工厂模式的应用提升为工厂模式的。
—04—
总结
工厂模式构造了一个与产品等级结构相同的工厂结构，每个子类工厂创建对应的具体产品。
工厂模式是简单模式的进一步抽象
所以想要理解工厂模式只需要理解清楚简单工厂模式即可。
工厂模式就是把简单工厂模式中的一类多能，上帝模式，转换为多个工厂类实例分摊职责。
可以认为简单工厂模式相当于封建专制，皇帝一个人说了算。
工厂模式就相当于民主制度下了，大家群策群力一起讨论，每个人负责一块。
抽象工厂角色Creator，可以使用接口也可以使用抽象类（不要用具体的类，因为这本身就是一个抽象角色）
如果具体的工厂之间有相同的逻辑，那么这些逻辑应该被提取到抽象类中。
否则
就应该使用接口的形式作为抽象工厂角色Creator和抽象产品角色Product。
需要注意的是
有很多类提供了很多的方法都能够返回一个具体的对象，比如toString方法，返回一个String。
那这算是工厂模式么？
严格的说这些并不属于工厂方法模式，因为这类方法主要是业务逻辑处理，重点在于业务逻辑，而不在于对象的创建。
出发点、逻辑、思想不是一回事，只不过返回了一个对象而已。
当然，个人看法~
https://mp.weixin.qq.com/s/9CT_6zLxl9tXHd1G2HTnbA
