思维导图

序言

在 Java 中，当使用new时，就会实例化一个具体类，但由于代码绑定了具体类，会导致代码变得更加脆弱，缺乏弹性。
比如说下面的代码：

1	Student student = new Student();

为了让代码具有弹性，我们需要使用接口：

1	People people = new Student();

虽然使用了接口，但我们需要建立具体类（Student）的实例。

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

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

对于上面的代码，究竟应该实例化哪个类呢？
具体来讲，这需要在运行时由一些条件（参数）来决定，但此做法却存在了一些问题。
当这样的代码一旦有变化或扩展，就必须重新打开这段代码进行检查和修改，因此会存在一些缺点：这样修改过的代码将造成部分系统变的更难以维护，更难以更新，也更容易出错。
那么，我们思考一下：new有什么不对劲的地方嘛？
在技术上，new没有错，毕竟这是 Java 的基础定义。真正要说的是“参数的改变”，以及它是如何影响new的使用的。
首先，我们是针对接口编程，这样可以隔离掉以后系统可能发生的一大堆改变。
为什么呢？
这是 Java 基础知识，若代码是针对接口而写，那么通过多态，它可以与任何实现该接口的新类建立联系。但是，当代码使用大量的具体类时，却无疑自寻烦恼，因为一旦加入新的具体类，就必须修改代码。
现在，我们得出了一个结论：以上代码并非“对修改关闭”，想要使用新的具体类型来扩展代码，必须重新打开并修改它。
那么，这就是个问题了，有了问题，自然需要解决，那么，如何解决该问题？
最好的办法是：去找出“变化”的代码，将其从“不变”的代码中分离出来，这时，便需要用到工厂模式啦！

那么，首先来了解下工厂模式的定义吧！

什么是工厂模式？

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

对于一个对象的创建而言：

可能会导致大量的重复代码
可能会需要复合对象访问不到的信息
也可能提供不了足够级别的抽象
还可能并不是复合对象概念的一部分
常常需要复杂的过程

因此，此类对象的创建不适合包含在一个复合对象中。
工厂方法模式通过定义一个单独的创建对象的方法来解决这些问题，由子类实现这个方法来创建具体类型的对象。

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

或许现在，你对这些概念还没有明确的认识与理解，但没关系，下面我们会通过一个例子来带你理解并熟悉它！

认识工厂模式

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

假如你要开一个包子店，你首先需要写一个包子类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类应该是一个接口（这里不合适）或抽象类（开始我们就这么定义的，虽然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时，你发现连锁店确实是用你的工厂创建包子，但是其他部分如包馅阶段、清蒸阶段可能采用它们自创的做法。你希望能够建立一个框架，把连锁店和创建包子捆绑在一起的同时又保持一定的弹性，那么如何得“鱼”又得“熊掌”呢？
我们可以这样做，把SimpleBunFactory中的createBun()方法放到BunStore中，不过要把它设置为“抽象方法”（首先将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的子类终究是子类，如何做决定呢？而且子类TianJinBunStore也没有看到任何做决定的逻辑代码啊！
答：这个应该从BunStore类的orderBun()方法来看，此方法在抽象的BunStore类中定义，但是只在子类中实现具体类型。

现在更进一步地，orderBun()方法对Bun对象做了许多事情（准备、发酵等等），但由于Bun是抽象的，orderBun()方法并不知道哪些具体类参与进来了，换句话说，这就是解耦。

如上图，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());

测试结果如下：

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

了解工厂模式

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

可以看到，将一个orderBun()方法和一个工厂方法联合起来，就可以成为一个框架。除此之外，工厂方法将生产知识封装进各个创建者，这样的做法，也可以被视为一个框架：

定义工厂方法模式

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

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

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

经常有开发人员说：工厂方法让子类决定要实例化的类是哪一个。希望不要理解错误，所谓的“决定”，并不是指模式允许子类本身在运行时做决定，而是指在编写创建者类时，不需要知道实际创建的产品是哪一个。选择了使用哪个子类，自然就决定了实际创建的产品是什么。

疑问解答

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

参考

Eric Freeman. HeadFirst 设计模式 [M]. 中国电力出版社，2007

文章信息

时间	说明
2020-08-28	文章重新排版，抽离出序言部分