建造者模式 - cbf4life - 博客园
11.1 变化是永恒的 &&&&& 又是一个周三，快要下班了，老大突然拉住我，喜滋滋地告诉我:“牛叉公司很满意我们做的模型，又签订了一个合同，把奔驰、宝马的车辆模型都交给我们公司制作了，不过这次又额外增加了一个新需求：汽车的启动、停止、喇叭声音、引擎声音都由客户自己控制，他想什么顺序就什么顺序，这个没问题吧?”
&&&&& 看着老大殷切的目光，我还能说啥？非常肯定地点头，“没问题！”，加班加点做呗，“再苦再累就当自己二百五！再难再险就当自己二皮脸！与君共勉！”这句话说出了俺的心声。
&&&&& 那任务是接下来，又是一个时间紧，工程量大的项目，为什么是“又”呢？因为基本上每个项目都是如此，我该怎么来完成这个任务呢？
&&&&& 首先我们分析一下需求，奔驰、宝马都是一个产品，他们有共有的属性，牛叉公司关心的是单个模型的运行过程：奔驰模型A是先有引擎声音，然后再响喇叭；奔驰模型B是先启动起来，然后再有引擎声音，这才是牛叉公司要关心的，那到我们老大这边呢，就是满足人家的要求，要什么顺序就立马能产生什么顺序的模型出来，我就负责把老大的要求实现出来，而且还要是批量的，也就是说牛叉公司下单订购宝马A车模，我们老大马上就找我“生产一个这样的车模，启动完毕后，喇叭响一下”，然后我们就准备开始批量生产这些模型。由我生产出N多个奔驰和宝马车辆模型，这些车辆模型的都有run()方法，但是具体到每一个模型的run()方法中间的执行任务的顺序是不同的，老大说要啥顺序，我就给啥顺序，最终客户买走后只能是既定的模型。好，需求还是比较复杂，我们先一个一个的解决，先从找一个最简单的切入点——产品类，每个车都是一个产品，如图11-1所示。
图11-1 汽车模型类图
&&&&& 类图比较简单，在CarModel中我们定义了一个setSequence方法，车辆模型的这几个动作要如何排布，是在这个ArrayList中定义的，然后run()方法根据sequence定义的顺序完成指定的顺序动作，与我们上一章节介绍的模板方法模式是不是非常类似？好，我们先看CarModel源代码，如代码清单11-1所示。
代码清单11-1 车辆模型的抽象类 public abstract class CarModel {
//这个参数是各个基本方法执行的顺序
private ArrayList&String& sequence = new ArrayList&String&();
//模型是启动开始跑了
protected abstract void start();
//能发动，那还要能停下来，那才是真本事
protected abstract void stop();
//喇叭会出声音，是滴滴叫，还是哔哔叫
protected abstract void alarm();
//引擎会轰隆隆地响，不响那是假的
protected abstract void engineBoom();
//那模型应该会跑吧，别管是人推的，还是电力驱动，总之要会跑
final public void run() {
//循环一边，谁在前，就先执行谁
for(int i=0;i&this.sequence.size();i++){
String actionName = this.sequence.get(i);
if(actionName.equalsIgnoreCase("start")){
this.start(); //开启汽车
}else if(actionName.equalsIgnoreCase("stop")){
this.stop(); //停止汽车
}else if(actionName.equalsIgnoreCase("alarm")){
this.alarm(); //喇叭开始叫了
}else if(actionName.equalsIgnoreCase("engine boom")){ //如果是engine boom关键字
this.engineBoom(); //引擎开始轰鸣
//把传递过来的值传递到类内
final public void setSequence(ArrayList&String& sequence){
this.sequence =
CarModel的设计原理是这样的，setSequence方法是允许客户自己设置一个顺序，是要先启动响一下喇叭再跑起来，还是要先响一下喇叭再启动，对于一个具体的模型永远都固定的，但是对N多个模型就是动态的了。在子类中实现父类的基本方法，run()方法读取sequence，然后遍历sequence中的字符串，哪个字符串在先，就先执行哪个方法。
两个实现类分别实现父类的基本方法，奔驰模型如代码清单11-2所示。
代码清单11-2 奔驰模型代码 public class BenzModel extends CarModel {
protected void alarm() {
System.out.println("奔驰车的喇叭声音是这个样子的...");
protected void engineBoom() {
System.out.println("奔驰车的引擎室这个声音的...");
protected void start() {
System.out.println("奔驰车跑起来是这个样子的...");
protected void stop() {
System.out.println("奔驰车应该这样停车...");
&&&&& 宝马车模型如代码清单11-3所示。
代码清单11-3 宝马模型代码 public class BMWModel extends CarModel {
protected void alarm() {
System.out.println("宝马车的喇叭声音是这个样子的...");
protected void engineBoom() {
System.out.println("宝马车的引擎室这个声音的...");
protected void start() {
System.out.println("宝马车跑起来是这个样子的...");
protected void stop() {
System.out.println("宝马车应该这样停车...");
&&&&& 两个产品的实现类都完成，我们来模拟一下牛叉公司的要求：生产1件奔驰模型，要求跑的时候，先发动引擎，然后再挂档启动，然后停下来，不需要喇叭。这个需求很容易满足，我们增加一个场景类实现该需求，如代码清单11-4所示。
代码清单11-4 宝马模型代码 public class Client {
public static void main(String[] args) {
* 客户告诉牛叉公司，我要这样一个模型，然后牛叉公司就告诉我老大
* 说要这样一个模型，这样一个顺序，然后我就来制造
BenzModel benz = new BenzModel();
//存放run的顺序
ArrayList&String& sequence = new ArrayList&String&();
sequence.add("engine boom"); //客户要求，run的时候时候先发动引擎
sequence.add("start"); //启动起来
sequence.add("stop"); //开了一段就停下来
//我们把这个顺序赋予奔驰车
benz.setSequence(sequence);
benz.run();
&&&&& 运行结果如下所示。
奔驰车的引擎是这个声音的...
奔驰车跑起来是这个样子的...
奔驰车应该这样停车...
&&&&& 看，我们组装了这样的一辆汽车，满足了牛叉公司的需求了。但是想想我们的需求，汽车的动作执行顺序是要能够随意调整的，我们只满足了一个需求，还要下一个需求呀，然后是第2件宝马模型，只要启动、停止，其他的什么都不要，第3件模型，先喇叭，然后启动，然后停止，第4件...直到把你逼疯为止，那怎么办？我们就一个一个的来写场景类满足吗？不可能了，那我们要想办法来解决这个问题，有了！我们为每种模型产品模型定义一个建造者，你要啥顺序直接告诉建造者，由建造者来建造，于是乎我们就有了如图11-2所示的类图。
图11-2 增加了建造者的汽车模型类图
&&&&& 增加了一个CarBuilder抽象类，由它来组装各个车模，要什么类型什么顺序的车辆模型，都由相关的子类完成，首先编写CarBuilder代码，如代码清单11-5所示。
代码清单11-5 抽象汽车组装者 public abstract class CarBuilder {
//建造一个模型，你要给我一个顺序要，就是组装顺序
public abstract void setSequence(ArrayList&String& sequence);
//设置完毕顺序后，就可以直接拿到这个车辆模型
public abstract CarModel getCarModel();
&&&&& 很简单，每个车辆模型都要有确定的运行顺序，然后才能返回一个车辆模型。奔驰车的组装者如代码清单11-6所示。
代码清单11-6 奔驰车组装者 public class BenzBuilder extends CarBuilder {
private BenzModel benz = new BenzModel();
public CarModel getCarModel() {
return this.
public void setSequence(ArrayList&String& sequence) {
this.benz.setSequence(sequence);
&&&&& 非常简单实用的程序，给定一个汽车的运行顺序，然后就返回一个奔驰车，简单了很多，宝马车的组装与此相同，如代码清单11-7所示。
代码清单11-7 宝马车组装者 public class BMWBuilder extends CarBuilder {
private BMWModel bmw = new BMWModel();
public CarModel getCarModel() {
return this.
public void setSequence(ArrayList&String& sequence) {
this.bmw.setSequence(sequence);
&&&&& 两个组装者都完成了，我们再来看看牛叉公司的需求如何满足，修改一下场景类，如代码清单11-8所示。
代码清单11-8 修改后的场景类 public class Client {
public static void main(String[] args) {
* 客户告诉牛叉公司，我要这样一个模型，然后牛叉公司就告诉我老大
* 说要这样一个模型，这样一个顺序，然后我就来制造
ArrayList&String& sequence = new ArrayList&String&(); //存放run的顺序
sequence.add("engine boom"); //客户要求，run的时候时候先发动引擎
sequence.add("start"); //启动起来
sequence.add("stop"); //开了一段就停下来
//要一个奔驰车：
BenzBuilder benzBuilder = new BenzBuilder();
//把顺序给这个builder类，制造出这样一个车出来
benzBuilder.setSequence(sequence);
//制造出一个奔驰车
BenzModel benz = (BenzModel)benzBuilder.getCarModel();
//奔驰车跑一下看看
benz.run();
&&&&& 运行结果如下所示。
奔驰车的引擎是这个声音的...
奔驰车跑起来是这个样子的...
奔驰车应该这样停车...
&&&&& 那如果我再想要个同样顺序的宝马车呢？很简单，再次修改一下场景类，如代码清单11-9所示。
代码清单11-9 相同顺序的宝马车的场景类 public class Client {
public static void main(String[] args) {
ArrayList&String& sequence = new ArrayList&String&(); //存放run的顺序
sequence.add("engine boom"); //客户要求，run的时候时候先发动引擎
sequence.add("start"); //启动起来
sequence.add("stop"); //开了一段就挺下来
//要一个奔驰车：
BenzBuilder benzBuilder = new BenzBuilder();
//把顺序给这个builder类，制造出这样一个车出来
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)简单了很多。我们在做项目时，经常会有一个共识：需求是无底洞，是无理性的，不可能你告诉它不增加需求就不增加，这四个过程（start、stop、alarm、engineBoom）按照排列组合有很多种，牛叉公司可以随意组合，它要什么顺序的车模我就必须生成什么顺序的车模，客户可是上帝！那我们不可能预知他们要什么顺序的模型呀，怎么办？封装一下，找一个导演，指挥各个事件的先后顺序，然后为每种顺序指定一个代码，你说一种我们立刻就给你生产处理，好方法，厉害！我们先修正一下类图，如图11-3所示。
图11-3 完整汽车模型类图
&&&&& 类图看着复杂了，但是还是比较简单，我们增加了一个Director类，负责按照指定的顺序生产模型，其中方法说明如下：
getABenzModel方法
&&&&& 组建出A型号的奔驰车辆模型，其过程为只有启动（start）、停止(stop)方法，其他的引擎声音、喇叭都没有。
getBBenzModel方法
&&&&& 组建出B型号的奔驰车，其过程为先发动引擎（engine boom）,然后启动(star),再然后停车(stop),没有喇叭。
getCBMWModel方法
&&&&& 组建出C型号的宝马车，其过程为先喇叭叫一下（alarm），然后（start）,再然后是停车(stop)，引擎不轰鸣。
getDBMWModel方法
&&&&& 组建出D型号的宝马车，其过程就一个启动(start)，然后一路跑到黑，永动机，没有停止方法，没有喇叭，没有引擎轰鸣。
&&&&& 其他的E型号、F型号……等等，可以有很多，启动(start)、停止(stop)、喇叭(alarm)、引擎轰鸣(engine boom)这四个方法在这个类中可以随意的自由组合，有几种呢？好像是排列组合，这个不会算，高中数学没学好，反正有很多种了，都可以实现。Director类如代码清单11-10所示。
代码清单11-10 导演类 public class Director {
private ArrayList&String& sequence = new ArrayList();
private BenzBuilder benzBuilder = new BenzBuilder();
private BMWBuilder bmwBuilder = new BMWBuilder();
* A类型的奔驰车模型，先start,然后stop,其他什么引擎了，喇叭一概没有
public BenzModel getABenzModel(){
//清理场景，这里是一些初级程序员不注意的地方
this.sequence.clear();
//这只ABenzModel的执行顺序
this.sequence.add("start");
this.sequence.add("stop");
//按照顺序返回一个奔驰车
this.benzBuilder.setSequence(this.sequence);
return (BenzModel)this.benzBuilder.getCarModel();
* B型号的奔驰车模型，是先发动引擎，然后启动，然后停止，没有喇叭
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型号的宝马车是先按下喇叭（炫耀嘛），然后启动，然后停止
public BMWModel getCBMWModel(){
this.sequence.clear();
this.sequence.add("alarm");
this.sequence.add("start");
this.sequence.add("stop");
this.bmwBuilder.setSequence(this.sequence);
return (BMWModel)this.bmwBuilder.getCarModel();
* D类型的宝马车只有一个功能，就是跑，启动起来就跑，永远不停止，牛叉
public BMWModel getDBMWModel(){
this.sequence.clear();
this.sequence.add("start");
this.bmwBuilder.setSequence(this.sequence);
return (BMWModel)this.benzBuilder.getCarModel();
* 这里还可以有很多方法，你可以先停止，然后再启动，或者一直停着不动，静态的嘛
* 导演类嘛，按照什么顺序是导演说了算
&&&&& 顺便说一下，大家看一下程序中有很多this调用，这个我一般是这样要求项目组成员的，如果你要调用类中的成员变量或方法，需要在前面加上this关键字，不加也能正常的跑起来，但是不清晰，加上this关键字，我就是要调用本类中成员变量或方法，而不是本方法的中的一个变量，还有super方法也是一样，是调用父类的的成员变量或者方法，那就加上这个关键字，不要省略，这要靠约束，还有就是程序员的自觉性，他要是死不悔改，那咱也没招。
&&&&& 注意 上面每个方法都一个this.sequence.clear()，这个估计你一看就明白，但是作为一个系统分析师或是技术经理一定要告诉告诉项目成员，ArrayList和HashMap如果定义成类的成员变量，那你在方法中调用一定要做一个clear的动作，防止数据混乱。如果你发生过一次类似问题的话，比如ArrayList中出现一个“出乎意料”的数据，而你又花费了几个通宵才解决这个问题，那你会有很深刻的印象。
&&&&& 有了这样一个导演类后，我们的场景类就更容易处理了，牛叉公司要A类型的奔驰车1W辆，B类型的奔驰车100W辆，C类型的宝马车1000W辆，D类型的不需要，非常容易处理，如代码清单11-11所示。
代码清单11-11 导演类 public class Client {
public static void main(String[] args) {
Director director = new Director();
//1W辆A类型的奔驰车
for(int i=0;i&10000;i++){
director.getABenzModel().run();
//100W辆B类型的奔驰车
for(int i=0;i&1000000;i++){
director.getBBenzModel().run();
//1000W辆C类型的宝马车
for(int i=0;i&;i++){
director.getCBMWModel().run();
&&&&& 清晰，简单吧，我们写程序重构的最终目的就是:简单、清晰，代码是让人看的，不是写完就完事了，我一直在教育我带的团队，Java程序不是像我们前辈写二进制代码、汇编一样，写完基本上就自己能看懂，别人看就跟看天书一样，现在的高级语言，要像写中文汉字一样，你写的，别人能看懂。——这就是建造者模式。
11.2 建造者模式的定义
&&&&& 建造者模式(Builder Pattern)也叫做生成器模式，其定义如下：
&&&&& Separate the construction of a complex object from its representation so that the same construction process can create different representations. 将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
&&&&& 建造者模式的通用类图如图11-4所示。
图11-4 建造者模式通用类图
&&&&& 在建造者模式中，有如下四个角色：
Product 产品类
&&&&& 通常是实现了模板方法模式，也就是有模板方法和基本方法，这个参考上一章节的模板方法模式。在例子中，BenzModel和BMWModel就属于产品类。
Builder 抽象建造者
&&&&& 规范产品的组建，一般是由子类实现。在例子中，CarBuilder属于抽象建造者。
ConcreteBuilder 具体建造者
&&&&& 实现抽象类定义的所有方法，并且返回一个组件好的对象。在例子中，BenzBuilder和BMWBuilder就属于具体建造者。
Director 导演
&&&&& 负责安排已有模块的顺序，然后告诉Builder开始建造，在上面的例子中就是我们的老大，牛叉公司找到老大，说我要这个，这个，那个类型的车辆模型，然后老大就把命令传递给我，我和我的团队就开始拼命的建造，于是一个项目建设完毕了。
&&&&& 建造者模式的通用源代码也比较简单，先看Product类，通常它是一个组合或继承（如模板方法模式）产生的类，如代码清单11-12所示。
代码清单11-12 产品类 public class Product {
public void doSomething(){
//独立业务处理
&&&&& 抽象建造者如代码清单11-13所示。
代码清单11-13 抽象建造者 public abstract class Builder {
//设置产品的不同部分，以获得不同的产品
public abstract void setPart();
//建造产品
public abstract Product buildProduct();
&&&&& 其中，setPart方法是零件的配置，什么是零件？其他的对象，获得一个不同零件，或者不同的装配顺序就可能产生不同的产品。具体的建造者如代码清单11-14所示。
代码清单11-14 具体建造者 public class ConcreteProduct extends Builder {
private Product product = new Product();
//设置产品零件
public void setPart(){
* 产品类内的逻辑处理
//组建一个产品
public Product buildProduct() {
&&&&& 需要注意的是，如果有多个产品类就有几个具体的建造者，而且这多个产品类具有相同接口或抽象类，参考我们上面的例子。
导演类如代码清单11-15所示。
代码清单11-15 导演类 public class Director {
private Builder builder = new ConcreteProduct();
//构建不同的产品
public Product getAProduct(){
builder.setPart();
* 设置不同的零件，产生不同的产品
return builder.buildProduct();
&&&&& 导演类就是起到封装的作用，避免高层模块深入到建造者内部的实现类。当然，在建造者模式比较庞大时，导演类可以有多个。
11.3 建造者模式的应用
&&&&& 1. 建造者模式的优点
&&&&& 使用建造者模式可以使客户端不必知道产品内部组成的细节，如例子中我们就不需要关心每一个具体的模型内部是如何实现的，产生的对象类型就是CarModel。
建造者独立，容易扩展
&&&&& BenzBuilder和BMWBuilder是相互独立的，对系统的扩展非常有利。
便于控制细节风险
&&&&& 由于具体的建造者是独立的，因此可以对建造过程逐步细化，而不对其他的模块产生任何影响。
&&&&& 2. 建造者模式的使用场景
相同的方法，不同的执行顺序，产生不同的事件结果时，可以采用建造者模式。
多个部件或零件,都可以装配到一个对象中，但是产生的运行结果又不相同时，则可以使用该模式。
产品类非常复杂，或者产品类中的调用顺序不同产生了不同的效能，这个时候使用建造者模式是非常合适。
在对象创建过程中会使用到系统中的一些其它对象，这些对象在产品对象的创建过程中不易得到时，也可以采用建造者模式封装该对象的创建过程。该种场景，只能是一个补偿方法，因为一个对象不容易获得，而在设计阶段竟然没有发觉，而要通过创建者模式柔化创建过程，本身已经违反设计最初目标。
&&&&& 3. 建造者模式的注意事项
&&&&& 建造者模式关注的是的零件类型和装配工艺（顺序），这是它与工厂方法模式最大不同的地方，虽然同为创建类模式，但是注重点不同。
11.4 建造者模式的扩展
&&&&& 已经不用扩展了，因为我们在汽车模型制造的例子中已经对建造者模式进行了扩展，引入了模板方法模式，可能大家会比较疑惑，为什么在其他介绍设计模式的书籍上创建者模式并不是这样说的，读者请注意，建造者模式中还有一个角色没有说明，就是零件，建造者怎么去建造一个对象？是零件的组装，组装顺序不同对象效能也不同，这才是建造者模式要表达的核心意义，而怎么才能更好的达到这种效果呢？引入模板方法模式是一个非常简单而有效的办法。
&&&&& 大家看到这里估计就开始犯嘀咕了，这个建造者模式和工厂模式非常相似呀，Yes，是的，是非常相似，但是记住一点你就可以游刃有余的使用了：建造者模式最主要功能是基本方法的调用顺序安排，也就是这些基本方法已经实现了，通俗的说就是零件的装配，顺序不同产生的对象也不同；而工厂方法则重点是创建，创建零件时它的主要职责，你要什么对象我创造一个对象出来，组装顺序则不是他关心的。
11.5 最佳实践
&&&&& 再次说明，在使用建造者模式的时候考虑一下模板方法模式，别孤立的思考一个模式，僵化的套用一个模式会让受害无穷！
如果你已经看懂本章节举的例子，并认可这种建造者模式，那你就放心使用，比单独使用某些书上的纯建造者是高效、简洁得多。
评论 - 212建造者模式实践 - ImportNew
| 标签： ,
我不打算跳入的过多细节中，因为已经有一大堆的文章和书籍很详细的解释过了。所以我打算告诉你为什么和什么时候你应该考虑使用设计模式。然而，值得一提的是本文中的模式和四人帮的一书中的提出的有点不一样。因为原生模式专注于抽象构建的步骤，所以通过使用不同的建造者的实现我们能得到不同的结果，然而在本文中解释的设计模式是讨论如何移除源自于多构造函数，多可选参数和滥用的setters方法中那些不必要的复杂的事物。
假设你有一个包含大量属性的类，就像下面的User类一样。让我们假设你想让这个类不可变（顺便说一句，除非你有一个真正的好理由，让你不必总是向着不可变这个目标奋斗。我们会在另一篇文章中讨论它）。
public class User {
private final String firstN
//required
private final String lastN
//required
//optional
private final S
//optional
private final S
//optional
现在想象一下，在你的类中有一些属性是必须的，有一些是可选的。你会如何创建这个类的实例？所有的属性都被声明成final类型，所以你必须在构造方法中设置它们，但是你也想让这个类的客户端有忽略可选属性的机会。
一个首先想到的可选方案是有一个构造方法是只接收必须属性作为参数，一个是接收所有必须属性和第一个可选属性，再一个是接收两个可选属性等等。这看起来会是什么样的？
看起来这样：
public User(String firstName, String lastName) {
this(firstName, lastName, 0);
public User(String firstName, String lastName, int age) {
this(firstName, lastName, age, '');
public User(String firstName, String lastName, int age, String phone) {
this(firstName, lastName, age, phone, '');
public User(String firstName, String lastName, int age, String phone, String address) {
this.firstName = firstN
this.lastName = lastN
this.age =
this.phone =
this.address =
这种构造对象的方式的好处是它可以正常工作。然而，这种方式的问题也是显而易见的。当你只有几个属性的时候不是什么大问题，但是随着属性个数的增加，代码变的越来越难阅读和维护。更重要的是，对客户端来说代码变得越来越难使用。
客户端里我该调用那一个构造方法？有两个参数那个？三个参数那个？我没有显示传值的那些参数的默认值都是什么？如何我只想给address属性设置一个值，但是不想给age和phone设置该怎么办？这种情况下，我不得不调用能接收所有参数的构造方法并传递默认值给那些我不关心的可选参数。另外，一些参数有相同的类型很容易混淆。第一个String类型参数对应的是phone还是address？
因此我们有什么其他选择来应对这种场景？我们可以总是遵循JavaBeans惯例，有一个默认的无参构造方法并且每个属性都有getter和setter方法。就象这样：
public class User {
private String firstN // required
private String lastN // required
// optional
private S // optional
//optional
public String getFirstName() {
return firstN
public void setFirstName(String firstName) {
this.firstName = firstN
public String getLastName() {
return lastN
public void setLastName(String lastName) {
this.lastName = lastN
public int getAge() {
public void setAge(int age) {
this.age =
public String getPhone() {
public void setPhone(String phone) {
this.phone =
public String getAddress() {
public void setAddress(String address) {
this.address =
这种方法看起来很容易阅读和维护。在客户端里我可以只创建一个空对象，然后只设置那些我感兴趣的属性。那么，这种方法有什么问题？这种解决方案有两个主要的问题。第一个问题是该类的实例状态不固定。如果你想创建一个User对象，该对象的5个属性都要赋值，那么直到所有的setXX方法都被调用之前，该对象都没有一个完整的状态。这意味着在该对象状态还不完整的时候，一部分客户端程序可能看见这个对象并且以为该对象已经构造完成。这种方法的第二个不足是User类是易变的。你将会失去不可变对象带来的所有优点。
幸运的是应对这种场景我们有第三种选择，建造者模式。解决方案类似如下所示：
public class User {
private final String firstN // required
private final String lastN // required
p // optional
private final S // optional
private final S // optional
private User(UserBuilder builder) {
this.firstName = builder.firstN
this.lastName = builder.lastN
this.age = builder.
this.phone = builder.
this.address = builder.
public String getFirstName() {
return firstN
public String getLastName() {
return lastN
public int getAge() {
public String getPhone() {
public String getAddress() {
public static class UserBuilder {
private final String firstN
private final String lastN
public UserBuilder(String firstName, String lastName) {
this.firstName = firstN
this.lastName = lastN
public UserBuilder age(int age) {
this.age =
public UserBuilder phone(String phone) {
this.phone =
public UserBuilder address(String address) {
this.address =
public User build() {
return new User(this);
一些值得注意的关键点：
User构造方法是私有的，这意味着该类不能在客户端代码里直接实例化。
该类现在又是不可变的了。所有属性都是final类型的，在构造方法里面被赋值。另外，我们只为它们提供了getter方法。
builder类使用，让客户端代码阅读起来更容易（我们马上就会看到一个它的例子）。
builder类构造方法只接收必须属性，为了确保这些属性在构造方法里赋值，只有这些属性被定义成final类型。
使用建造者模式有在本文开始时提到的两种方法的所有优点，并且没有它们的缺点。客户端代码写起来更简单，更重要的是，更易读。我听过的关于该模式的唯一批判是你必须在builder类里面复制类的属性。然而，考虑到这个事实，builder类通常是需要建造的类的一个静态类成员，它们一起扩展起来相当容易。
现在，试图创建一个新的User对象的客户端代码看起来如何那？让我们来看一下：
public User getUser() {
return new
User.UserBuilder('Jhon', 'Doe')
.phone('9;)
.address('Fake address ;)
非常整洁，是不是？你可以只用一行代码就创建一个User对象，更重要的是，代码很易读。此外，我们也确保无论何时你获得一个该类的对象，该对象都不会是一个不完整的状态。
这个模式是非常灵活的。一个单独的builder类可以通过在调用build方法之前改变builder的属性来创建多个对象。builder类甚至可以在每次调用之间自动补全一些生成的字段，例如一个id或者序列号。
很重要的一点是，例如构造方法，builder类可以在构造方法参数上增加约束。build方法可以检查这些约束，如果不满足就抛出一个IllegalStateException异常。
至关重要的是要在builder的参数拷贝到建造对象之后在验证参数，这样验证的就是建造对象的字段，而不是builder的字段。这么做的原因是builder类不是线程安全的，如果我们在创建真正的对象之前验证参数，参数值可能被另一个线程在参数验证完和参数被拷贝完成之间的时间修改。这段时间周期被称作“脆弱之窗”。在我们User的例子中，类似代码如下：
public User build() {
User user = new user(this);
if (user.getAge() 120) {
throw new IllegalStateException(“Age out of range”); // thread-safe
上一个代码版本是线程安全的因为我们首先创建user对象，然后在不可变对象上验证条件约束。下面的代码在功能上看起来一样但是它不是线程安全的，你应该避免这么做：
public User build() {
if (age 120) {
throw new IllegalStateException(“Age out of range”); // bad, not thread-safe
// This is the window of opportunity for a second thread to modify the value of age
return new User(this);
建造者模式最后的一个优点是builder可以作为参数传递给一个方法，让该方法有为客户端创建一个或者多个对象的能力，而不需要知道创建对象的任何细节。为了这么做你可能通常需要一个如下所示的简单接口：
public interface Builder {
T build();
借用之前的User例子，UserBuilder类可以实现Builder。如此，我们可以有如下的代码：
UserCollection buildUserCollection(Builder&? extends User& userBuilder){...}
好吧，这确实是一篇很长的文章，虽然是第一次发。总而言之，建造者模式在多于几个参数（虽然不是很科学准确，但是我通常把四个参数作为使用建造者模式的一个很好的指示器），特别是当大部分参数都是可选的时候。你可以让客户端代码在阅读，写和维护方面更容易。另外，你的类可以保持不可变特性，让你的代码更安全。
UPDATE：如果你使用作为IDE，你有相当多的插件来避免编写建造者模式大部分的重复代码劳动。我已知的有下面三个：
/a/eclipselabs.org/p/bob-the-builder/
/p/fluent-builders-generator-eclipse-plugin/
这几个插件我都没有使用过，所以关于哪个更好，我无法给出一个有经验的决定。我估计其他IDEs也会存在类型的插件。
原文链接：
- 译文链接： [ 转载请保留原文出处、译者和译文链接。]
关于作者：
译文和原文有点出入 已经更新了
关于ImportNew
ImportNew 专注于 Java 技术分享。于日 11:11正式上线。是的，这是一个很特别的时刻 :)
ImportNew 由两个 Java 关键字 import 和 new 组成，意指：Java 开发者学习新知识的网站。 import 可认为是学习和吸收， new 则可认为是新知识、新技术圈子和新朋友……
新浪微博：
推荐微信号
反馈建议：@
广告与商务合作QQ：
– 好的话题、有启发的回复、值得信赖的圈子
– 写了文章？看干货？去头条！
– 为IT单身男女服务的征婚传播平台
– 优秀的工具资源导航
– 活跃 & 专业的翻译小组
– 国内外的精选博客文章
– UI,网页，交互和用户体验
– JavaScript, HTML5, CSS
– 专注Android技术分享
– 专注iOS技术分享
– 专注Java技术分享
– 专注Python技术分享
& 2016 ImportNew}