什么是工厂模式？

  工厂方法模式（英语：Factory method pattern）是一种实现了“工厂”概念的面向对象设计模式。就像其他创建型模式一样，它也是处理在不指定对象具体类型的情况下创建对象的问题。工厂方法模式的实质是“定义一个创建对象的接口，但让实现这个接口的类来决定实例化哪个类。工厂方法让类的实例化推迟到子类中进行。”^[1]

  创建一个对象常常需要复杂的过程，所以不适合包含在一个复合对象中。创建对象可能会导致大量的重复代码，可能会需要复合对象访问不到的信息，也可能提供不了足够级别的抽象，还可能并不是复合对象概念的一部分。工厂方法模式通过定义一个单独的创建对象的方法来解决这些问题。由子类实现这个方法来创建具体类型的对象。

  对象创建中的有些过程包括决定创建哪个对象、管理对象的生命周期，以及管理特定对象的创建和销毁的概念。

认识工厂模式

  当使用new时，就会实例化一个具体类，而代码绑着具体类会导致代码更脆弱，更缺乏弹性。因此需要使用接口来让代码具有弹性，但还是得建立具体类(Student)的实例，如下面的代码：

People people = new Student();

  当有一群相关的具体类时，通常会写出下面的代码：

    People people;
    if(study){
        people = new Student();
    }else if(teach){
        people = new Teacher();
    }else if(work){
        people = new Worker();
    }

  这里有一些要实例化的具体类，究竟该实例化哪个类，要在运行时由一些条件来决定。
  当这样的代码一旦有变化或扩展，就必须重新打开这段代码进行检查和修改。通常这样修改过的代码将造成部分系统更难维护和更新，而且也更容易犯错。
  new有什么不对劲呢？
  在技术上，new没有错，毕竟这是Java的基础定义。真正要说的是“改变”，以及它是如何影响new的使用的。
  针对接口编程，可以隔离掉以后系统可能发生的一大堆改变。为什么呢？如果代码是针对接口而写，那么通过多态，它可以与任何新类实现该接口。但是，当代码使用大量的具体类时，等于是自找麻烦，因为一旦加入新的具体类，就必须改变代码。也就是说，你的代码并非“对修改关闭”。想要使用新的具体类型来扩展代码，必须重新打开它。这就是个问题了，因此我们应当找出“变化”的代码，将其从“不变”的代码中分离出来。

一个例子开始了解工厂模式

  假如你要开一个包子店，你首先需要写一个包子类Bun来描述包子的详细信息，各种包子都要继承这个父类，该类代码如下：

public abstract class Bun {
    String name;//包子名称
    String dough;//面团种类
    String stuffing;//馅的种类

    //准备阶段
    void prepare() {
        System.out.println("将面粉和酵母水混合搅拌捏成团");
    }

    //发酵阶段
    void ferment() {
        System.out.println("将面团盖上保鲜膜放置一到两小时");
    }

    //切片阶段
    void cut() {
        System.out.println("将面团揉成长条切成小份，揉成小团");
    }

    //包馅阶段
    void farci() {
        System.out.println("把准备好的馅放进面团中间，再整理好形状");
    }

    //清蒸阶段
    void steam() {
        System.out.println("将包子放进蒸笼清蒸");
    }

    //打包阶段
    void box() {
        System.out.println("将蒸完的包子打包好");
    }

    public String getName() {
        return name;
    }
}

  有了基本的包子类，你就可以卖包子了，所以还需要一个包子店铺类BunStore，代码如下：

public class BunStore {
    //订购包子
    public Bun orderBun(){
        Bun bun = new Bun();

        bun.prepare();
        bun.ferment();
        bun.cut();
        bun.farci();
        bun.steam();
        bun.box();

        return bun;
    }
}

  但是包子的种类不可能是单一的，所以要作出一些变化，而且为了使系统更有弹性，我们的Bun类应该是一个抽象类或接口(开始我们就这么定义的)，改变后的代码：

public class BunStore {
    //订购包子
    public Bun orderBun(String type) {
        Bun bun = null;

        //具体包子种类的英文太长，此处用拼音代替
        if (type.equals("三鲜")) {
            bun = new SanXianBun();
        } else if (type.equals("蛋黄")) {
            bun = new DanHuangBun();
        } else if (type.equals("豆沙")) {
            bun = new DouShaBun();
        } else {
            return null;
        }

        bun.prepare();
        bun.ferment();
        bun.cut();
        bun.farci();
        bun.steam();
        bun.box();

        return bun;
    }
}

  但是作为一个小商人，肯定会关注包子的销量情况，如果豆沙包卖的不好，可能将其下架换上另一种类的包子。而且有些馅的包子是不同季节才有的。因此，我们上面的代码可能频繁地变化(if语句的内容频繁增加删除)。
  “变化”？那就像策略模式一样，将“变化”的代码抽离出来封装不就行了。其中包子的加工流程是不怎么变化的，变化的是订购包子的种类，将其抽离出变为一个类，这个新对象就叫工厂：

public class SimpleBunFactory {
    public Bun createBun(String type){
        Bun bun = null;
        //具体包子种类的英文太长，此处用拼音代替
        if (type.equals("三鲜")) {
            bun = new SanXianBun();
        } else if (type.equals("蛋黄")) {
            bun = new DanHuangBun();
        } else if (type.equals("豆沙")) {
            bun = new DouShaBun();
        } else {
            return null;
        }
        return bun;
    }
}

  该工厂处理创建对象的细节，之后修改下原来的BunStore代码：

public class BunStore {
    SimpleBunFactory factory;
    
    //将工厂作为参数传入构造器
    public BunStore(SimpleBunFactory factory) {
        this.factory = factory;
    }

    //订购包子
    Bun orderBun(String type) {
        Bun bun = factory.createBun(type);

        bun.prepare();
        bun.ferment();
        bun.cut();
        bun.farci();
        bun.steam();
        bun.box();

        return bun;
    }
}

  问：这样做有什么好处？似乎只是把问题搬到另一个对象罢了，问题仍然存在。
  答：``SimpleBunFactory该工厂可以有许多客户，现在是只有一个orderBun方法是它的客户，但未来可能还有BunShopMenu(包子店菜单)类，会利用这个工厂来取得包子的价钱和描述，或者其他更多的客户。总而言之，该工厂可以有许多的客户。因此，把创建包子的代码包装进一个类，当以后需要实现改变时，只需修改这个类即可。
  问：经常在代码中看到把工厂定义为静态的方法，这有何差别？
  答：利用静态方法定义一个简单的工厂常被称作静态工厂。为何使用静态方法？因为不需要使用创建对象的方法来实例化对象。但也有缺点，那就是不能通过继承来改变创建方法的行为。

定义简单工厂(非设计模式)

  简单工厂其实不是一个设计模式，反而比较像是一种编程习惯。虽然它不是一个真正的模式，但了解其用法还是很有必要，让我们看看新的包子店类图：

改进原有例子

  假如你的包子店经营有成，希望在别的地方开加盟店。身为加盟公司经营者，不得不考虑不同地域包子风味的问题，天津的包子有天津的特色，陕西的包子有陕西的特色。
  如果利用工厂SimpleBunFactory，写出多种不同的工厂：TianJinBunFactory、ShanXiBunFactory，那么各地的加盟店都有合适的工厂可以使用，代码如下：

TianJinBunFactory tjFactory = new TianJinBunFactory();
BunStore tjStore = new BunStore();
tjStore.orderBun("三鲜");

ShanXiBunFactory sxFactory = new ShanXiBunFactory();
BunStore sxStore = new BunStore();
sxFactory.orderBun("三鲜");

  在推广工厂SimpleBunFactory时，你发现加盟店确实是用你的工厂创建包子，但是其他部分如包馅阶段、清蒸阶段可能采用它们自创的做法。你希望能够建立一个框架，把加盟店和创建包子捆绑在一起的同时又保持一定的弹性，那么如何得“鱼”又得“熊掌”呢？
  我们可以这样做，把createBun方法放到BunStore中，不过要把它设置为“抽象方法”，然后为不同地域的加盟店创建不同的BunStore的子类。首先看看BunStore的改变：

public abstract class BunStore {
    //订购包子
    public final Bun orderBun(String type) {
        //从工厂对象移回BunStore
        Bun bun = createBun(type);

        bun.prepare();
        bun.ferment();
        bun.cut();
        bun.farci();
        bun.steam();
        bun.box();

        return bun;
    }

    //把工厂对象移到这个方法中，该方法是抽象的
    protected abstract Bun createBun(String type);
}

  现在有了一个BunStore作为父类，让每个加盟店(天津包子铺，陕西包子铺)子类都继承自这个BunStore，每个子类各自决定如何制造包子，让我们看看现在的类图：

  如上图，BunStore对象通过orderBun()方法调用createBun()方法取得包子对象，但究竟会取得哪一种包子对象呢？这不是由orderBun()方法所能决定的，那么究竟是谁决定呢？当然是具体的包子铺(TianJinBunStore、ShanXiBunStore)来决定啦。
  那么，这些包子店子类是实时做出这样的决定吗？不是的，但从orderBun()方法的角度来看，如果选择在TianJinBunStore这个子类店订购包子，则由这个子类店来决定。严格来说，并非由这个子类店实际做决定，而是看顾客选择哪个包子店，此时才决定了包子的风味。
  下面是TianJinBunStore的代码：

public class TianJinBunStore extends BunStore {
    @Override
    protected Bun createBun(String type) {
        Bun bun = null;
        //具体包子种类的英文太长，此处用拼音代替
        if (type.equals("三鲜")) {
            bun = new TianJinSanXianBun();
        } else if (type.equals("蛋黄")) {
            bun = new TianJinDanHuangBun();
        } else if (type.equals("豆沙")) {
            bun = new TianJinDouShaBun();
        } else {
            return null;
        }
        return bun;
    }
}

//天津口味的不同类型的包子
public class TianJinDouShaBun extends Bun {
    public TianJinDouShaBun() {
        name = "天津风味的豆沙包";
        dough = "普通的面团";
        stuffing = "豆沙馅";
    }
}

public class TianJinSanXianBun extends Bun {
    public TianJinSanXianBun() {
        name = "天津风味的三鲜包";
        dough = "上等面团";
        stuffing = "猪肉芹菜馅";
    }
}

public class TianJinDanHuangBun extends Bun {
    public TianJinDanHuangBun() {
        name = "天津风味的蛋黄包";
        dough = "劲道的面团";
        stuffing = "蛋黄馅";
    }
}

  可以看到，TianJinBunStore类继承自BunStore类，创建的包子都是天津口味的，陕西包子铺的代码类似。
  我们在回头讲解一下BunStore代码：

public abstract class BunStore {
    //订购包子
    public final Bun orderBun(String type) {
        //从工厂对象移回BunStore
        Bun bun = createBun(type);

        bun.prepare();
        bun.ferment();
        bun.cut();
        bun.farci();
        bun.steam();
        bun.box();

        return bun;
    }

    //把工厂对象移到这个方法中，该方法是抽象的
    protected abstract Bun createBun(String type);
}

  原本是由一个对象负责所有具体类的实例化，现在通过对BunStore类做的改变，变成由一堆子类来负责实例化。而且，现在实例化包子的则类被转移到createBun()方法中，此方法就如同一个工厂。
  工厂方法用来处理对象的创建，并将这样的行为封装在子类中。这样，客户程序中关于超类的代码就和子类对象创建代码解耦了：

测试例子

  终于到了测试包子店的时候了，订购包子的流程如下：
①首先需要实例化一个地区加盟的包子店；
②然后在这个店里订购相应种类的包子；
③之后就可以获取订购到的包子的详细信息了。

        BunStore tjStore = new TianJinBunStore();
        Bun bun = tjStore.orderBun("豆沙");

        System.out.println("有顾客订购了" + bun.getName());

  测试结果如下：

将面粉和酵母水混合搅拌捏成团
将面团盖上保鲜膜放置一到两小时
将面团揉成长条切成小份，揉成小团
把准备好的馅放进面团中间，再整理好形状
将包子放进蒸笼清蒸
将蒸完的包子打包好
有顾客订购了天津风味的豆沙包

了解工厂模式

  没错，上面这些类又、用到了工厂模式。
  所有工厂模式都用来封装对象的创建。工厂方法模式通过让子类决定该创建的对象是什么，来达到将对象创建的过程封装的目的。我们来看看它们的类图：

定义工厂方法模式

  下面是工厂方法模式的正式定义：

  工厂方法模式：定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个，工厂方法让类把实例化推迟到子类。

  工厂方法模式能够封装具体类型的实例化。如下面的类图，抽象的Creator提供了一个创建对象的方法的接口，也称为“工厂方法”。在抽象的Creator中，任何其他实现的方法，都可能使用到这个工厂方法所制造出来的产品，但只有子类真正实现这个工厂方法并创建产品。

疑问解答

  问：当只有一个ConcreteCreator的时候，工厂方法模式有什么优点？
  答：尽管只有一个具体创建者，工厂方法模式依然很有用，因为它帮助我们将产品的“实现”从“使用”中解耦。如果增加产品或者改变产品的实现，Creator并不会收到影响，因为它们两者直接都不是紧耦合。
  问：如果说天津包子店是利用简单工厂创建的，这样的说法是否正确？看起来很像。
  答：不正确。它们很类似，但用法不同。虽然每个具体商店的实现看起来都很像是SimpleBunFactory，但别忘了，工厂方法模式里的具体实现是扩展自一个BunStore类，此类有一个抽象方法createBun()，由每个商店自行负责createBun()方法的行为。而在简单工厂中，工厂是另一个由BunStore使用的对象。
  问：工厂方法和创建者是否总是抽象的？
  答：不是的，可以定义一个默认的工厂方法来产生某些具体的产品，这么一来，即使创建者没有任何子类，依然可以创建产品。
  问：每个商店基于传入的参数制造出不同种类的包子。是否所有的具体创建者都必须如此？能不能只创建一种包子？
  答：我们采用的方式称为“参数化工厂方法”，它可以根据传入的参数创建不同的对象。但是工厂经常只产生一种对象，所以此时可以不需要参数化。工厂模式的这两种形式都是有效的。
  问：简单工厂和工厂方法之间的差异令人很困惑，看起来很类型，差别在于，在工厂方法中，返回包子的类是子类，如何解释？
  答：子类的确看起来很像简单工厂，而简单工厂把全部的事情在一个地方都处理完成，然而工厂方法却是创建一个框架，让子类决定要如何实现。比方说，在工厂方法中，orderBun()方法提供了一般的框架，以便创建包子，orderBun()依赖于工厂方法创建具体类，并制造出实际的包子。可通过继承自BunStore类，决定实际制造出的包子是什么。简单工厂的做法，可以将对象的创建封装起来，但是简单工厂不具备工厂方法的弹性，因为简单工厂不能变更正在创建的产品。
  问：那么这些所谓的“工厂”究竟能带来什么好处？
  答：有许多好处。将创建对象的代码集中在一个对象或方法中，可以避免代码中的重复，并且更方便以后的维护。这也意味着客户在实例化对象时，只依赖于接口，而不是具体类。针对接口编程，可以让代码更具有弹性，应对未来的扩展。

参考资料

《HeadFirst设计模式》