一、概述
上一节[简单工厂模式]介绍了通过工厂创建对象以及简单的利弊分析；这一节来看看工厂方法模式对类的创建
工厂方法模式:
工厂方法与简单工厂的不同，主要体现在简单工厂的缺点的改进：
工厂类不再负责产品的创建，工厂角色变成了抽象工厂的角色（工厂不再需要知道所有产品的细节）
父类负责定义创建对象的公共接口，而子类则负责生成具体的对象，这样做的目的是将类的实例化操作延迟到子类中完成，即由子类来决定究竟应该实例化（创建）哪一个类。
这些改进的思想，来源与简单工厂中拓展难的弊端，体现的是之前六大原则中描述的——封装变化！
UML图：
平行的等级结构，创建结构与产品结构平行，最简单的情况如下所示：
当然可以像下图一样拓展任意个产品与创建者：
可以看出，工厂方法是对简单工厂的进一步抽象！
当然为了说明问题，再举一个现实生活中的例子：
对于运动鞋来说有很多品牌（361°，特步等等），相应的也有不同的厂生成对应的鞋，这里361°等鞋就是具体的产品，而361°的厂则是工厂，专门负责生成对应的鞋。如果哪天想尝试新的品牌了（乔丹等），只需联系响应的工厂（创建工厂）即可。
也就是说，顾客的鞋的等级结构与工厂的等级结构是一样的。提供产品不再只由一个工厂提供了。只需对顾客提供一个管理不同鞋厂的总厂（抽象工厂），而创建产品也延后到了它的各个工厂子类进行创建了！
客户端调用前并不知道具体的返回类型，返回的是一个抽象类型的引用，它指向具体的实现类！
二、实践
按照上面的例子，创建相应的代码：
抽象工厂：
/**
* 抽象工厂类
* 作者： Administrator
* 日期： 2017/10/26
**/
public interface ShoeFactory {
Shoe factoryMethod();
}
抽象产品：
/**
* 抽象产品类
* 作者： Administrator
* 日期： 2017/10/26
**/
public interface Shoe {
}
具体工厂类：
/**
* 子工厂：耐克工厂类
* 作者： Administrator
* 日期： 2017/10/26
**/
public class NikeShoeFactory implements ShoeFactory{
@Override
public Shoe factoryMethod() {
return new NikeShoe();
}
}
具体产品：
/**
* 具体产品类：耐克鞋
* 作者： Administrator
* 日期： 2017/10/26
**/
public class NikeShoe implements Shoe{
}
客户端调用：
/**
* 客户端
* 作者： Administrator
* 日期： 2017/10/26
**/
public class Client {
public static void main(String[] args) {
ShoeFactory shoeFactory = new NikeShoeFactory();
Shoe shoe = shoeFactory.factoryMethod();
System.out.println(shoe);
}
}
三、改进与思考
对于工厂方法模式，拓展是很容的。以上述例子为例，要新增鞋子，只需增加一个鞋子的类，再增加一个对应的工厂，而之前的完全不受影响。
而且是符合开闭原则的，不会需要到代码中去修改，而是对拓展开放。
并且，根据阿里规范，对于使用了设计模式的地方，命名应当让人一眼看出使用了设计模式！
当然，也可以有与简单工厂类似的循环利用对象而不是每次都创建新对象的变种。