设计模式：Builder模式

Builder模式主要用于构建复杂的对象，对象的各个部件可能会有剧烈变化，而构建的过程是固定的。这个时候就可以使用Builder模式把对象的构建过程抽取出来。

 

作用 ：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。


举例来讲 ，同样一批建筑工人，都会打地基，砌砖，贴瓷砖等等基本的建筑操作，也就是说，你可以用他们来盖商业楼，盖住宅小区，甚至造桥筑路什么的。当然，一个非常重要的条件就是，你要提供工程师来指导他们到底按照怎么样的顺序做才能完成一个特定的建筑物。这里的工程师就是Director的角色，而建筑工人就是Builder的角色。
你提供一个筑路工程师，那么这些建筑工人就可以筑出路来；你提供一个住宅工程师，那么就可以造出一幢住宅楼来。也就是说，Builder只负责创建基本的物件，并且可以在Director的指导下完成一系列的构建工作。在不同的Director的指导下，他们可以创建出各种不同类型的产品来。

 

图例：

以下是我按照自己的理解画出来的两幅UML图，其中Builder模式的核心思想都是一样的，只不过在具体的使用方法有一点点区别。

其中，Builder是建筑工人，Director是工程师，Product是要创建出来的产品，而Cilent就相当于某一个建筑类公司的大老板。

 

图一：

 

图二：

 

本例中两幅UML图的不同就是老板（Client端）到底要问谁要构建出来的产品？
之前在网上看到过类似的讨论。有些朋友认为，Director只有指导之责，真正负责创建产品的还是Builder，所以要问Builder要产品，这也是Builder模式最初的画法。而另外一些朋友认为，我都已经把Builder交给你Director了，最后当然要直接问你要产品了。
现在想想，这个问题其实并没有涉及到Builder模式的核心思想，两者都是合理的。
只不过对于图二来讲，Director必然要认识Product，也就是说，和Product耦合了。在具体设计的时候，就需要仔细考虑这个问题，采用这种方式设计的话，到底会不会对整个系统未来的扩展有影响。

 

优点
1、建造者模式的“加工工艺”是暴露的，这样使得建造者模式更加灵活，可替换。
2、解耦了组装过程和创建具体部件，使得我们不用去关心每个部件是如何组装的。

缺点
1、上面的第1点优点也可以说是建造者模式的缺点，因为“加工工艺”的暴露，使此模式不太“优雅”。

 

适用性
1、需要生成的产品对象有复杂的内部结构。如果很简单的话，那么使用这个模式可能就没有必要了。
2、需要生成的产品对象的属性相互依赖，建造者模式可以强迫生成顺序。
3、在对象创建过程中会使用到系统中的一些其它对象，这些对象在产品对象的创建过程中不易得到。

与工厂模式的区别：
工厂模式主要是涉及到产品的创建，并且产品只有极其简单的构建过程或者根本就不需要额外的构建。
而Builder模式则恰恰相反，它主要构建有复杂的构建过程的产品。

工厂模式一般涉及多个产品的创建，而builder模式只负责创建一个产品。