（转）设计模式（Design Patterns）笔记之四：Builder yakuu [原作]

前言：看着csdn渐渐让人失望，本来打算不写了。可是老师们教我善始善终，呵呵，那就坚持一回吧。

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

---------------------------------------------------------------------------------------

“嘿，Andy，来帮帮忙，帮我装装机子吧。”，Helen又在那喳喳呼呼了。

“好的，好的，喔……，新机诶！”，走过去一看，AndyTao眼一亮。唉，看到人家的新配置，他就有一种据为己有的冲动。说实在的，咱玩电脑的，没几个不这山望着那山高的。。。

“这么大个丫头，到现在还是不会装机器。你怎么学的啊？”AndyTao嘴上这么说，心里想，“最好永远学不会！”

“好的，好的，谢谢你嘛！不过，如果能把你的脑子也装过来就好了。”

“嘿，不是吧，要求过分。。。。。。这样吧，嗯，顺便给你说说设计模式吧！”

“这装机也是个设计模式？”

“听下去！”

“哦。。。”，Helen噘嘴的样子真TMD可爱，AndyTao不觉想入非非了。

“我就给你说说设计模式里的Builder模式好了。Builder模式是一步一步创建一个复杂的对象，它允许用户可以只通过指定复杂对象的类型和内容就可以构建它们。用户不知道内部的具体构建细节。”

“诶，这个和抽象工厂模式不是很相似么？”

“Builder模式是非常类似抽象工厂模式,细微的区别大概只有在反复使用中才能体会到。待会我讲讲Builder和Abstract Factory模式之间的一些区别好了。”

“它一般用在下面两种情况下：
1、当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。
2、当构造过程必须允许被构造的对象有不同的表示时。
上面的说法太抽象。简单点来说，它是为了将构建复杂对象的过程和它的部件解耦，从而达到将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。”

“不懂……具体的来说呢？”

“因为一个复杂的对象，有大量组成部分，有时候多得让人头晕，就拿PC机来说吧：PC机有很多部件：

主板，CPU，硬盘，显示器……还有各种小零件，配件等等；部件很多，如何将这些部件装配成一台PC？

这个装配过程也很复杂，需要很好的组装技术(还吓不着你？)，那么我们为了更好的组织PC机这个大对象，就需要一种相应的方法来进行装配。我们要说的Builder模式也就是为了将部件和组装过程分开而产生的。”

“不明白……”

“唉，笨笨，拿你没办法……”

“这样吧，我们说说具体怎么使用先！”

“首先假设一个复杂对象是由多个部件组成的，Builder模式是把复杂对象的创建和部件的创建分别开来，分别用Builder类和Director类来表示。”

“首先,需要一个接口,它定义如何创建复杂对象的各个部件:

public interface Builder {

　　//创建部件A　比如生产主板
　　void buildPartA();
　　//创建部件B 比如生产CPU
　　void buildPartB();
　　//创建部件C 比如生产硬盘
　　void buildPartC();
……
　　//返回最后组装成品结果 (返回最后装配好的PC)
　　//成品的组装过程不在这里进行，而是转移到下面的Director类中进行。
　　//从而实现了过程和部件的分离
　　Product getProduct();
}

用Director构建最后的复杂对象,而在上面Builder接口中封装的是如何创建一个个部件(复杂对象是由这

些部件组成的),也就是说Director的内容是如何将部件最后组装成成品:

public class Director {

　　private Builder builder;

　　public Director( Builder builder ) {
　　　　this.builder = builder;
　　}
　　// 将部件partA partB partC最后组成复杂对象
　　//这里是将主板、CPU和硬盘组装成PC的过程
　　public void construct() {
　　　　builder.buildPartA();
　　　　builder.buildPartB();
　　　　builder.buildPartC();
　　}
}

Builder的具体实现ConcreteBuilder:
通过具体完成接口Builder来构建或装配产品的部件;
定义并明确它所要创建的是什么具体东西;
提供一个可以重新获取产品的接口:

public class ConcreteBuilder implements Builder {

　　Part partA, partB, partC;
　　public void buildPartA() {
　　　　//这里是具体如何构建partA的代码
　　};
　　public void buildPartB() {
　　　　//这里是具体如何构建partB的代码
　　};
　　 public void buildPartC() {
　　　　//这里是具体如何构建partB的代码
　　};
　　 public Product getProduct() {
　　　　//返回最后组装成品结果
　　};
}

复杂对象：产品Product：

public interface Product { }

复杂对象的部件：

public interface Part { }

我们看看如何调用Builder模式：
ConcreteBuilder builder = new ConcreteBuilder();
Director director = new Director( builder );
director.construct();
Product product = builder.getProduct(); ”

“上面所讲的就是Builder模式的一般性使用方法了。至于Builder和Abstract Factory模式的区别，Builder强调的是整体是由部分组成的这个概念，比如你想要得到PC这个复杂对象，那你一定要先准备好主板，CPU，硬盘等等这些构造PC所必须的简单对象，之后调用Builder的get操作得到PC这个最终产品；

而Abstract Factory模式则并不强调这种关系，或者可以说是构造上的‘松耦合’。”

“嗯，咱们来个形象点的比喻吧：Builder模式是用来制造产品的，你的角色相当于产品制造商，知道怎么用部件来制造产品，而部件来自部件制造商，你可以利用不同种类的部件，也可以用同种类的部件采用不同的制造方法。而Abstract Factory是从用户角度来考虑的，主要是给用户提供产品系列，用户可以方便的使用这些产品系列，但是用户没有可能去改变产品，只能使用已有的产品系列。
例如：Builder模式适用于计算机发烧友，经常DIY的；而Abstract Factory模式适用于喜欢稳定的品牌机，像IBM，联想之类的。”

“你的意思是不是，constructor依次调用Builder的buildPart方法，全部完成后再调用getProduct方法得到整个product？那为什么不在Builder中加一个construct方法，依次调用自己的buildPart方法呢？这样还可以减少constructor和Builder之间的耦合。或者说，这种调用是运行时确定的，所以无法写在Builder中间吗？”

“还是上面所说的，如果将构造过程放在Builder里来作，那就失去的构造的灵活性。还拿PC来说吧，如果你在Builder里构造一种PC，80G硬盘的；但是你又想构造另外一种PC，100G硬盘的；你绝对不愿意再修改你的Builder吧，所以Builder用来构造Part，而整体的结构就由另外的一个Director来得到。简单点来说，就是由你自己去组合这些零件，最后调用get方法得到你要的product。”

“在Java实际使用中，我们经常用到‘池’(Pool)的概念,当资源提供者无法提供足够的资源,并且这些资源需要被很多用户反复共享时,就需要使用池了。‘池’实际是一段内存，当池中有一些复杂的资源的‘残余’(比如数据库的连接池，也许有时一个连接会中断)，如果循环再利用这些‘残余’，将提高内存使用效率，提高池的性能。重在组装！”

“哦也，我有点明白了……你真行啊！”

“哪里哪里！！！”

“你以为我夸你哪？？？我说你弄半天还没有帮我把机子装好，你真行啊！！！”

“我晕……倒！你个小妮子！”