什么是工厂模式？
工厂方法模式（英语：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的子类终究是子类，如何做决定？而且子类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类，决定实际制造出的包子是什么。简单工厂的做法，可以将对象的创建封装起来，但是简单工厂不具备工厂方法的弹性，因为简单工厂不能变更正在创建的产品。
问：那么这些所谓的“工厂”究竟能带来什么好处？
答：有许多好处。将创建对象的代码集中在一个对象或方法中，可以避免代码中的重复，并且更方便以后的维护。这也意味着客户在实例化对象时，只依赖于接口，而不是具体类。针对接口编程，可以让代码更具有弹性，应对未来的扩展。
参考资料
《HeadFirst设计模式》