建造者模式

一.定义

建造者模式(Builder Pattern)也叫做生成器模式，其定义如下:
Separate the construction of a complex object from its representation so that the sameconstruction process can create different representations. (将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。)
建造者通用结构

在建设者模式中,有四个角色.
Product产品类
通常是实现了模板方法模式，也就是有模板方法和基本方法，这个参考第10章的模板方法模式。例子中的BenzModel和BMWModel就属于产品类。
Builder抽象建造者
规范产品的组建，一般是由子类实现。例子中的CarBuilder就属于抽象建造者。ConcreteBuilder具体建造者·
实现抽象类定义的所有方法，并且返回一个组建好的对象。例子中的BenzBuilder和BMWBuilder就属于具体建造者。
Director导演类
负责安排已有模块的顺序，然后告诉Builder开始建造，在上面的例子中就是我们的老大，XX公司找到老大，说我要这个或那个类型的车辆模型，然后老大就把命令传递给我，我和我的团队就开始拼命地建造，于是一个项目建设完毕了。
建造者模式的通用源代码也比较简单，先看Product类，通常它是一个组合或继承（如模板方法模式）产生的类，如代码如下:
产品类

抽象建造者类
具体建造者
其中，setPart方法是零件的配置，什么是零件?其他的对象，获得一个不同零件，或者不同的装配顺序就可能产生不同的产品。具体的建造者如代码如下:

导演类

需要注意的是，如果有多个产品类就有几个具体的建造者，而且这多个产品类具有相同接口或抽象类，参考我们上面的例子。

二.例子

接着上一个模板方法的故事,继续往下讲,
又是一个周三，快要下班了，老大突然拉住我，喜滋滋地告诉我:“XX公司很满意我们做的模型，又签订了一个合同，把奔驰、宝马的车辆模型都交给我们公司制作了，不过这次又额外增加了一个新需求:汽车的启动、停止、喇叭声音、引擎声音都由客户自己控制，他想什么顺序就什么顺序，这个没问题吧?”
那任务又是一个时间紧，工程量大的项目，为什么是“又”呢?因为基本上每个项目都是如此，我该怎么来完成这个任务呢?
首先，我们分析一下需求，奔驰、宝马都是一个产品，它们有共有的属性，XX公司关心的是单个模型的运行过程:奔驰模型A是先有引擎声音，然后再响喇叭。奔驰模型B是先启动起来，然后再有引擎声音，这才是XX公司要关心的。那到我们老大这边呢，就是满足人家的要求，要什么顺序就立马能产生什么顺序的模型出来。我就负责把老大的要求实现出来，而且还要是批量的，也就是说XX公司下单订购宝马A车模，我们老大马上就找我“生产一个这样的车模，启动完毕后，喇叭响一下”，然后我们就准备开始批量生产这些模型。由我生产出N多个奔驰和宝马车辆模型，这些车辆模型都有run(方法，但是具体到每一个模型的run(方法中间的执行任务的顺序是不同的，老大说要啥顺序，我就给啥顺序,客户买走后只能是既定的模型。好，需求还是比较复杂，我们先一个一个地解决，先从
找一个最简单的切入点——产品类
先来看基本的类图

类图比较简单，在CarModel中我们定义了一个setSequence方法，车辆模型的这几个动作要如何排布，是在这个ArrayList中定义的。然后run()方法根据sequence定义的顺序完成指定的顺序动作，与上次介绍的模板方法模式是不是非常类似?那接下来,让我们来看看源码
车辆模型抽象类

CarModel的设计原理是这样的，setSequence方法是允许客户自己设置一个顺序，是要先启动响一下喇叭再跑起来，还是要先响一下喇叭再启动。对于一个具体的模型永远都固定的，但是对N多个模型就是动态的了。在子类中实现父类的基本方法，run()方法读取sequence，然后遍历sequence中的字符串、哪个字符串在先，就先执行哪个方法。

两个类分别实现父类的方法
奔驰模型代码

宝马车模型

两个产品的实现类都完成，我们来模拟一下XX公司的要求:生产一个奔驰模型，要求跑的时候，先发动引擎，然后再挂挡启动，然后停下来，不需要喇叭。这个需求很容易满足，我们增加一个场景类实现该需求，如代码如下

运行结果如下:

看，我们组装了这样的一辆汽车，满足了XX公司的需求。但是想想我们的需求，汽车的动作执行顺序是要能够随意调整的。我们只满足了一个需求，还要下一个需求呀，然后是第二个宝马模型，只要启动、停止，其他的什么都不要，第三个模型，先喇叭，然后启动，然后停止，第四个……直到把你逼疯为止，那怎么办?我们就一个一个地来写场景类满足吗?不可能了，那我们要想办法来解决这个问题，有了!我们为每种模型产品模型定义一个建造者，你要啥顺序直接告诉建造者，由建造者来建造，于是乎我们就有了如图所示的类图。

增加了一个CarBuilder抽象类，由它来组装各个车模，要什么类型什么顺序的车辆模型,都由相关的子类完成。首先编写CarBuilder代码，如代码如下所示。
抽象汽车组装者

奔驰车组装者

宝马车组装者

修改后的业务流程代码

运行结果

那如果我再想要个同样顺序的宝马车呢?很简单，再次修改一下场景类，如代码如下所示。

运行结果

看，同样运行顺序的宝马车也生产出来了，而且代码是不是比刚开始直接访问产品类(Procuet）简单了很多。我们在做项目时，经常会有一个共识:需求是无底洞，是无理性的，不可能你告诉它不增加需求就不增加，这4个过程（start、stop、alarm、engineBoom）按照排列组合有很多种，XX公司可以随意组合，它要什么顺序的车模我就必须生成什么顺序的车模，
客户可是上帝!那我们不可能预知他们要什么顺序的模型呀，怎么办?封装一下，找一个导演，指挥各个事件的先后顺序，然后为每种顺序指定一个代码，你说一种我们立刻就给你生产处理，好方法，厉害!我们先修改一下类图，如图:

类图看着复杂了，但还是比较简单，我们增加了一个Director类，负责按照指定的顺序生产模型，其中方法说明如下:

• getABenzModel方法
  组建出A型号的奔驰车辆模型，其过程为只有启动（start)、停止(stop）方法，其他的引擎声音、喇叭都没有。
• getBBenzModel方法
  组建出B型号的奔驰车，其过程为先发动引擎(engine boom)，然后启动，再然后停车，没有喇叭。
• getCBMWModel方法
  组建出C型号的宝马车，其过程为先喇叭叫一下(alarm)，然后启动，再然后是停车，引擎不轰鸣。
• getDBMWModel方法
  组建出D型号的宝马车，其过程就一个启动，然后一路跑到黑，永动机，没有停止方法，没有喇叭，没有引擎轰鸣。

导演类


顺便说一下，大家看一下程序中有很多this调用。这个我一般是这样要求项目组成员的，如果你要调用类中的成员变量或方法，需要在前面加上this关键字，不加也能正常的跑起来，但是不清晰，加上this关键字，我就是要调用本类中的成员变量或方法，而不是本方法的中的一个变量。还有super方法也是一样，是调用父类的成员变量或者方法，那就加上这个关键字，不要省略，这要靠约束，还有就是程序员的自觉性，他要是死不悔改，那咱也没招。

有了这样一个导演类后，我们的场景类就更容易处理了，XX公司要A类型的奔驰车1万辆，B类型的奔驰车100万辆，C类型的宝马车1000万辆，D类型的不需要，非常容易处理，如代码

清晰、简单吧，我们写程序重构的最终目的就是:简单、清晰。代码是让人看的，不危写完就完事了，我一直在教育我带的团队成员，Java程序不是像我们前辈写二进制代码、汇编一样，写完基本上就自己能看懂，别人看就跟看天书一样，现在的高级语言，要像写中文汉字一样，你写的，别人能看懂。这就是建造者模式。

三.结论

优点

• 封装性
  使用建造者模式可以使客户端不必知道产品内部组成的细节，如例子中我们就不需要关心每一个具体的模型内部是如何实现的，产生的对象类型就是CarModel。
• 建造者独立，容易扩展
  BenzBuilder和BMWBuilder是相互独立的，对系统的扩展非常有利。
• 便于控制细节风险
  由于具体的建造者是独立的，因此可以对建造过程逐步细化，而不对其他的模块产生任何影响。

缺点

难以应付"分步骤构建算法"的需求变动.

使用场景

• 相同的方法，不同的执行顺序，产生不同的事件结果时，可以采用建造者模式。
  多个部件或零件，都可以装配到一个对象中，但是产生的运行结果又不相同时，则可以
  使用该模式。
• 产品类非常复杂，或者产品类中的调用顺序不同产生了不同的效能，这个时候使用建造者模式非常合适。
• 在对象创建过程中会使用到系统中的一些其他对象，这些对象在产品对象的创建过程中不易得到时，也可以采用建造者模式封装该对象的创建过程。该种场景只能是一个补偿方法，因为一个对象不容易获得，而在设计阶段竟然没有发觉，而要通过创建者模式柔化创建过程，本身已经违反设计的最初目标。