目录
一、基本概念
建造者模式（Builder Pattern）也叫做生成器模式，其定义如下：Separate the construction of a complex object from its representation so that the same constructionprocess can create different representations.（将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。）
二、通俗解释
BUILDER建造者模式：MM最爱听的就是“我爱你”这句话了，见到不同地方的MM,要能够用她们的方言跟她说这句话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到MM我只要按对应的键，它就能够用相应的语言说出“我爱你”这句话了，国外的MM也可以轻松搞掂，这就是我的“我爱你”builder。（这一定比美军在伊拉克用的翻译机好卖） 建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。
产品的内部表象
一个产品常有不同的组成成分作为产品的零件，这些零件有可能是对象，也有可能不是对象，它们通常又叫做产品的内部表象（internal representation）。不同的产品可以有不同的内部表象，也就是不同的零件。使用建造模式可以使客户端不需要知道所生成的产品有哪些零件，每个产品的对应零件彼此有何不同，是怎么建造出来的，以及怎么组成产品。
三、建造者模式详解
1.造车的例子
又是一个周三，快要下班了，老大突然拉住我，喜滋滋地告诉我：“××公司很满意我们做的模型，又签订了一个合同，把奔驰、宝马的车辆模型都交给我们公司制作了，不过这次又额外增加了一个新需求：汽车的启动、停止、喇叭声音、引擎声音都由客户自己控制，他想什么顺序就什么顺序，这个没问题吧？”那任务又是一个时间紧、工程量大的项目，为什么是“又”呢？因为基本上每个项目都是如此，我该怎么来完成这个任务呢？
首先，我们分析一下需求，奔驰、宝马都是一个产品，它们有共有的属性，××公司关心的是单个模型的运行过程：奔驰模型A是先有引擎声音，然后再响喇叭；奔驰模型B是先启动起来，然后再有引擎声音，这才是××公司要关心的。那到我们老大这边呢，就是满足人家的要求，要什么顺序就立马能产生什么顺序的模型出来。我就负责把老大的要求实现出来，而且还要是批量的，也就是说××公司下单订购宝马A车模，我们老大马上就找我“生产一个这样的车模，启动完毕后，喇叭响一下”，然后我们就准备开始批量生产这些模型。由我生产出N多个奔驰和宝马车辆模型，这些车辆模型都有run()方法，但是具体到每一个模型的run()方法中间的执行任务的顺序是不同的，老大说要啥顺序，我就给啥顺序，最终客户买走后只能是既定的模型。好，需求还是比较复杂，我们先一个一个地解决，先从找一个最简单的切入点——产品类，每个车都是一个产品，如图所示。
类图比较简单，在CarModel中我们定义了一个setSequence方法，车辆模型的这几个动作要如何排布，是在这个ArrayList中定义的。然后run()方法根据sequence定义的顺序完成指定的顺序动作，与第10章介绍的模板方法模式是不是非常类似？好，我们先看CarModel源代码。
车辆模型的抽象类
public abstract class CarModel {
/**
* 各个基本方法的执行顺序
*/
private ArrayList<String> sequence = new ArrayList<>();
/**
* 模型启动开始跑了
*/
abstract void start();
/**
* 能发动，还要能停下来，那才是真本事
*/
abstract void stop();
/**
* 喇叭会出声音，是滴滴叫，还是哔哔叫
*/
abstract void alarm();
/**
* 引擎会轰隆轰地响，不响那是假的
*/
abstract void engineBoom();
/**
* 是车都会跑吧，别管是人推的，还是电动的，总之要会跑
*/
final public void run(){
//循环一遍，谁在前，就先执行谁
for (String actionName : this.sequence) {
switch (actionName) {
case "start":
this.start();
break;
case "stop":
this.stop();
break;
case "alarm":
this.alarm();
break;
case "engine boom":
this.engineBoom();
break;
default:
break;
}
}
}
/**
* 把传递过来的值传递到类里面
* @param sequence
*/
final public void setSequence(ArrayList<String> sequence){
this.sequence = sequence;
}
}CarModel的设计原理是这样的，setSequence方法是允许客户自己设置一个顺序，是要先启动响一下喇叭再跑起来，还是要先响一下喇叭再启动。对于一个具体的模型永远都固定的，但是对N多个模型就是动态的了。在子类中实现父类的基本方法，run()方法读取sequence，然后遍历sequence中的字符串，哪个字符串在先，就先执行哪个方法。
两个实现类分别实现父类的基本方法。
奔弛模型类
public class BenzModel extends CarModel {
@Override
void start() {
System.out.println("奔弛跑起来是这样子的。。。");
}
@Override
void stop() {
System.out.println("奔弛应该是这样停车的。。。");
}
@Override
void alarm() {
System.out.println("奔弛的喇叭声音是这样的。。。");
}
@Override
void engineBoom() {
System.out.println("奔弛的引擎声音是这样的。。。");
}
}宝马模型类
public class BMWModel extends CarModel {
@Override
void start() {
System.out.println("宝马跑起来是这样子的。。。");
}
@Override
void stop() {
System.out.println("宝马应该是这样停车的。。。");
}
@Override
void alarm() {
System.out.println("宝马的喇叭声音是这样的。。。");
}
@Override
void engineBoom() {
System.out.println("宝马的引擎声音是这样的。。。");
}
}
两个产品的实现类都完成，我们来模拟一下××公司的要求：生产一个奔驰模型，要求跑的时候，先发动引擎，然后再挂挡启动，然后停下来，不需要喇叭。这个需求很容易满足，我们增加一个客户端类实现该需求。
public class Client {
public static void main(String[] args) {
//客户告诉XX公司，我要这样一个模型，然后XX公司就告诉我老大
//说要这样一个模型，这样一个顺序，然后我就来制造
BenzModel benz = new BenzModel();
//存放run的顺序
ArrayList<String> sequence = new ArrayList<>();
sequence.add("engine boom");
sequence.add("start");
sequence.add("stop");
benz.setSequence(sequence);
benz.run();
}
}运行结果如下所示：
奔弛的引擎声音是这样的。。。
奔弛跑起来是这样子的。。。
奔弛应该是这样停车的。。。
看，我们组装了这样的一辆汽车，满足了××公司的需求。但是想想我们的需求，汽车的动作执行顺序是要能够随意调整的。我们只满足了一个需求，还有下一个需求呀，然后是第二个宝马模型，只要启动、停止，其他的什么都不要；第三个模型，先喇叭，然后启动，然后停止；第四个……直到把你逼疯为止，那怎么办？我们就一个一个地来写场景类满足吗？不可能了，那我们要想办法来解决这个问题，有了！我们为每种模型产品模型定义一个建造者，你要啥顺序直接告诉建造者，由建造者来建造，于是乎我们就有了如下图所示的类图。
增加了一个CarBuilder抽象类，由它来组装各个车模，要什么类型什么顺序的车辆模型，都由相关的子类完成。首先编写CarBuilder代码。
抽象汽车组装者
public abstract class CarBuilder {
/**
* 建造一个模型，你要给我一个顺序要求，就是组装顺序
* @param sequence
*/
public abstract void setSequence(ArrayList<String> sequence);
/**
* 设置完毕顺序后，就可以直接拿到这个车辆模型
* @return
*/
public abstract CarModel getCarModel();
}很简单，每个车辆模型都要有确定的运行顺序，然后才能返回一个车辆模型。
奔驰车组装者类
public class BenzBuilder extends CarBuilder {
private BenzModel benz = new BenzModel();
@Override
public void setSequence(ArrayList<String> sequence) {
this.benz.setSequence(sequence);
}
@Override
public CarModel getCarModel() {
return this.benz;
}
}非常简单实用的程序，给定一个汽车的运行顺序，然后就返回一个奔驰车，简单了很多。宝马车的组装与此相同。
宝马车组装者类
public class BMWBuilder extends CarBuilder {
private BMWModel bmw = new BMWModel();
@Override
public void setSequence(ArrayList<String> sequence) {
this.bmw.setSequence(sequence);
}
@Override
public CarModel getCarModel() {
return this.bmw;
}
}两个组装者都完成了，我们再来看看××公司的需求如何满足，修改一下客户端类。
修改后的客户端类
public class Client {
public static void main(String[] args) {
//客户告诉XX公司，我要这样一个模型，然后XX公司就告诉我老大
//说要这样一个模型，这样一个顺序，然后我就来制造
//存放run的顺序
ArrayList<String> sequence = new ArrayList<>();
sequence.add("engine boom");
sequence.add("start");
sequence.add("stop");
BenzBuilder benzBuilder = new BenzBuilder();
benzBuilder.setSequence(sequence);
BenzModel benz = (BenzModel) benzBuilder.getCarModel();
benz.run();
}
}运行结果如下所示：
奔弛的引擎声音是这样的。。。
奔弛跑起来是这样子的。。。
奔弛应该是这样停车的。。。
那如果我再想要个同样顺序的宝马车呢？很简单，再次修改一下客户端类。
相同顺序的宝马车的客户端类
public class Client {
public static void main(String[] args) {
//客户告诉XX公司，我要这样一个模型，然后XX公司就告诉我老大
//说要这样一个模型，这样一个顺序，然后我就来制造
//存放run的顺序
ArrayList<String> sequence = new ArrayList<>();
sequence.add("engine boom");
sequence.add("start");
sequence.add("stop");
//建造一个奔弛
BenzBuilder benzBuilder = new BenzBuilder();
benzBuilder.setSequence(sequence);
BenzModel benz = (BenzModel) benzBuilder.getCarModel();
benz.run();
//按照相同顺序，再建造一个宝马
BMWBuilder bmwBuilder = new BMWBuilder();
bmwBuilder.setSequence(sequence);
BMWModel bmw = (BMWModel) bmwBuilder.getCarModel();
bmw.run();
}
}运行结果如下所示：
奔弛的引擎声音是这样的。。。
奔弛跑起来是这样子的。。。
奔弛应该是这样停车的。。。
宝马的引擎声音是这样的。。。
宝马跑起来是这样子的。。。
宝马应该是这样停车的。。。
看，同样运行顺序的宝马车也生产出来了，而且代码是不是比刚开始直接访问产品类（Procuct）简单了很多。我们在做项目时，经常会有一个共识：需求是无底洞，是无理性的，不可能你告诉它不增加需求就不增加，这4个过程（start、stop、alarm、engine boom）按照排列组合有很多种，××公司可以随意组合，它要什么顺序的车模我就必须生成什么顺序的车模，客户可是上帝！那我们不可能预知他们要什么顺序的模型呀，怎么办？封装一下，找一个导演，指挥各个事件的先后顺序，然后为每种顺序指定一个代码，你说一种我们立刻就给你生产处理，好方法，厉害！我们先修改一下类图，如图所示。
类图看着复杂了，但还是比较简单，我们增加了一个Director类，负责按照指定的顺序生产模型，其中方法说明如下：●getABenzModel方法
组建出A型号的奔驰车辆模型，其过程为只有启动（start）、停止（stop）方法，其他的引擎声音、喇叭都没有。
●getBBenzModel方法
组建出B型号的奔驰车，其过程为先发动引擎（engine boom），然后启动，再然后停车，没有喇叭。
●getCBMWModel方法
组建出C型号的宝马车，其过程为先喇叭叫一下（alarm），然后启动，再然后是停车，引擎不轰鸣。
●getDBMWModel方法
组建出D型号的宝马车，其过程就一个启动，然后一路跑到黑，永动机，没有停止方法，没有喇叭，没有引擎轰鸣。其他的E型号、F型号……可以有很多，启动、停止、喇叭、引擎轰鸣这4个方法在这个类中可以随意地自由组合。
导演类
public class Director {
private ArrayList<String> sequence = new ArrayList<>();
private BenzBuilder benzBuilder = new BenzBuilder();
private BMWBuilder bmwBuilder = new BMWBuilder();
/**
* A类型奔弛
* @return
*/
public BenzModel getABenzModel(){
this.sequence.clear();
this.sequence.add("start");
this.sequence.add("stop");
this.benzBuilder.setSequence(this.sequence);
return (BenzModel) this.benzBuilder.getCarModel();
}
/**
* B类型奔弛
* @return
*/
public BenzModel getBBenzModel(){
this.sequence.clear();
this.sequence.add("engine boom");
this.sequence.add("start");
this.sequence.add("stop");
this.benzBuilder.setSequence(this.sequence);
return (BenzModel) this.benzBuilder.getCarModel();
}
/**
* C类型宝马
* @return
*/
public BMWModel getCBMWModel(){
this.sequence.clear();
this.sequence.add("alarm");
this.sequence.add("start");
this.sequence.add("stop");
this.benzBuilder.setSequence(this.sequence);
return (BMWModel) this.bmwBuilder.getCarModel();
}
/**
* D类型宝马
* @return
*/
public BMWModel getDBMWModel(){
this.sequence.clear();
this.sequence.add("start");
this.benzBuilder.setSequence(this.sequence);
return (BMWModel) this.bmwBuilder.getCarModel();
}
//还可以有很多方法，导演说了算。。。
}顺便说一下，大家看一下程序中有很多this调用。这个我一般是这样要求项目组成员的，如果你要调用类中的成员变量或方法，需要在前面加上this关键字，不加也能正常地跑起来，但是不清晰，加上this关键字，我就是要调用本类中的成员变量或方法，而不是本方法中的一个变量。还有super方法也是一样，是调用父类的成员变量或者方法，那就加上这个关键字，不要省略，这要靠约束，还有就是程序员的自觉性，他要是死不悔改，那咱也没招。
注意 上面每个方法都有一个this.sequence.clear()，估计你一看就明白。但是作为一个系统分析师或是技术经理一定要告诉项目成员，ArrayList和HashMap如果定义成类的成员变量，那你在方法中的调用一定要做一个clear的动作，以防止数据混乱。如果你发生过一次类似问题的话，比如ArrayList中出现一个“出乎意料”的数据，而你又花费了几个通宵才解决这个问题，那你会有很深刻的印象。
有了这样一个导演类后，我们的场景类就更容易处理了，××公司要A类型的奔驰车1万辆，B类型的奔驰车100万辆，C类型的宝马车1000万辆，D类型的不需要，非常容易处理。
客户端类
public class Client {
public static void main(String[] args) {
Director director = new Director();
//建造1万辆A类型奔弛
for (int i = 0; i < 10000; i++) {
director.getABenzModel().run();
}
//建造10万辆B类型奔弛
for (int i = 0; i < 100000; i++) {
director.getBBenzModel().run();
}
//建造100万辆C类型宝马
for (int i = 0; i < 1000000; i++) {
director.getCBMWModel().run();
}
//建造1000万辆D类型宝马
for (int i = 0; i < 10000000; i++) {
director.getDBMWModel().run();
}
}
}清晰、简单吧，我们写程序重构的最终目的就是：简单、清晰。代码是让人看的，不是写完就完事了，我一直在教育我带的团队成员，Java程序不是像我们前辈写二进制代码、汇编一样，写完基本上就自己能看懂，别人看就跟看天书一样，现在的高级语言，要像写中文汉字一样，你写的，别人能看懂。这就是建造者模式。
2.建造者模式的结构
建造者模式的通用类图如图所示。
在建造者模式中，有如下4个角色：
●Product产品类
通常是实现了模板方法模式，也就是有模板方法和基本方法，这个参考第10章的模板方法模式。例子中的BenzModel和BMWModel就属于产品类。
●Builder抽象建造者
规范产品的组建，一般是由子类实现。例子中的CarBuilder就属于抽象建造者。
●ConcreteBuilder具体建造者
实现抽象类定义的所有方法，并且返回一个组建好的对象。例子中的BenzBuilder和BMWBuilder就属于具体建造者。
●Director导演类
负责安排已有模块的顺序，然后告诉Builder开始建造，在上面的例子中就是我们的老大，××公司找到老大，说我要这个或那个类型的车辆模型，然后老大就把命令传递给我，我和我的团队就开始拼命地建造，于是一个项目建设完毕了。
建造者模式的通用源代码也比较简单，先看Product类，通常它是一个组合或继承（如模板方法模式）产生的类。
public class Product{
public void doSomething(){
//独立业务处理
}
}抽象建造者
public abstract class Builder {
//设置产品的不同部分，以获得不同的产品
public abstract void setPart();
//建造产品
public abstract Product buildProduct();
}其中，setPart方法是零件的配置，什么是零件？其他的对象，获得一个不同零件，或者不同的装配顺序就可能产生不同的产品。
具体建造者
public class ConcreteProduct extends Builder{
private Product product = new Product();
//设置产品零件
public void setPart(){
//产品类内的逻辑处理
}
//组建一个产品
public Product buildProduct(){
return product;
}
}需要注意的是，如果有多个产品类就有几个具体的建造者，而且这多个产品类具有相同接口或抽象类，参考我们上面的例子。
导演类
public class Director{
private Builder builder = new ConcreteProduct();
//建造不同的产品
public Product getAProduct(){
builder.setPart();
//设置不同的零件，产生不同的产品
return builder.buildProduct();
}
}导演类起到封装的作用，避免高层模块深入到建造者内部的实现类。当然，在建造者模式比较庞大时，导演类可以有多个。
3.建造者模式的优点
● 封装性
使用建造者模式可以使客户端不必知道产品内部组成的细节，如例子中我们就不需要关心每一个具体的模型内部是如何实现的，产生的对象类型就是CarModel。
● 建造者独立，容易扩展
BenzBuilder和BMWBuilder是相互独立的，对系统的扩展非常有利。
● 便于控制细节风险
由于具体的建造者是独立的，因此可以对建造过程逐步细化，而不对其他的模块产生任何影响。
4.使用场景
相同的方法，不同的执行顺序，产生不同的事件结果时，可以采用建造者模式。
多个部件或零件，都可以装配到一个对象中，但是产生的运行结果又不相同时，则可以使用该模式。
产品类非常复杂，或者产品类中的调用顺序不同产生了不同的效能，这个时候使用建造者模式非常合适。
在对象创建过程中会使用到系统中的一些其他对象，这些对象在产品对象的创建过程中不易得到时，也可以采用建造者模式封装该对象的创建过程。该种场景只能是一个补偿方法，因为一个对象不容易获得，而在设计阶段竟然没有发觉，而要通过创建者模式柔化创建过程，本身已经违反设计的最初目标。
5.注意事项
建造者模式关注的是零件类型和装配工艺（顺序），这是它与工厂方法模式最大不同的地方，虽然同为创建类模式，但是注重点不同。
四、建造者模式的扩展和最佳实践
建造者模式的扩展
已经不用扩展了，因为我们在汽车模型制造的例子中已经对建造者模式进行了扩展，引入了模板方法模式。可能大家会比较疑惑，为什么在其他介绍设计模式的书籍上创建者模式并不是这样说的？读者请注意，建造者模式中还有一个角色没有说明，就是零件，建造者怎么去建造一个对象？是零件的组装，组装顺序不同对象效能也不同，这才是建造者模式要表达的核心意义，而怎么才能更好地达到这种效果呢？引入模板方法模式是一个非常简单而有效的办法。
大家看到这里估计就开始犯嘀咕了，这个建造者模式和工厂模式非常相似呀，是的，非常相似，但是记住一点你就可以游刃有余地使用了：建造者模式最主要的功能是基本方法的调用顺序安排，也就是这些基本方法已经实现了，通俗地说就是零件的装配，顺序不同产生的对象也不同；而工厂方法则重点是创建，创建零件是它的主要职责，组装顺序则不是它关心的。
最佳实践
再次说明，在使用建造者模式的时候考虑一下模板方法模式，别孤立地思考一个模式，僵化地套用一个模式会让你受害无穷！如果你已经看懂本书举的例子，并认可这种建造者模式，那你就放心使用，比单独使用建造者高效、简洁得多。
参考秦小波的《设计模式之禅（第2版）》