在回顾设计模式之工厂模式1_简单工厂中，所有的产品(Hamburg)的实例化都是在SimpleFactory中完成。想想这样的场景，KFC和McDonald等等商家都销售Hamburg，每个商家的Hamburg又各具特色。我们的SimpleFactory是不是要被改疯的节奏？回顾工厂方法后，我们就不再怕怕啦~~~

工厂方法（Factory Method）

基于上面的场景，每个客户商家需要创建不同风味的产品Hamburg，那完成可以把createHamburg的任务分配给具体的客户。我们先把每个具体的客户特征抽象出来，看看下面的HamburgStore。

//代码片段1
public abstract class HamburgStore {

    public Hamburg orderHamburg(String type) {

        Hamburg hamburg = createHamburg(type);
        hamburg.prepare();
        hamburg.make();
        hamburg.box();
        return hamburg;
    }

    //工厂方法
    protected abstract Hamburg createHamburg(String type);
}

McDonaldStore,KFCStore与HamburgStore的UML关系如下：

需要关注一下几点：

1. HamburgStore是抽象类；
2. createHamburg方法是抽象方法；
3. McDonaldStore，KFCStore是具体的，继承HamburgStore。
4. 实现createHamburg抽象方法，完成创建各自的产品Hamburg。抽象的客户HamburgStore把创建产品的细节开放给子类具体客户，由子类决定创建产品。

工厂方法模式的定义

在抽象客户中定义了一个创建对象的接口，由子类具体客户决定产品具体实例化细节，把产品的实例化推迟到子类具体客户中。

1. 所有的产品必须实现Product接口，这样在客户中，我们只需要引用Product,而不关心具体产品ConcreteProduct；
2. 抽象客户Creator提供了创建对象的接口factoryMethod(工厂方法)；
3. 具体客户ConcreteCreator继承自Creator，必须实现factoryMethod方法;
4. 具体客户ConcreteCreator负责创建具体产品，只有ConcreteCreator知晓产品的创建过程和细节。

工厂方法模式的优点：

1. Creator和Product都是抽象的，遵守“要依赖抽象，不要依赖具体类”的设计原则；
2. 帮助我们把产品Product的生产和使用分离，达到解耦的目的，典型的解耦框架；
3. 具体客户Creator分担产品Product创建的压力，使得结构变得灵活起来；
4. 符合“系统对扩展开放，对修改关闭”原则;

工厂方法模式的使用场景：

1. 需要把客户代码从实例化的具体类中解耦出来；
2. 或者目前不知道需要实例化哪些具体类时，也可以使用。