004.设计模式之Builder模式

004.设计模式之Builder模式

场景:

在Abstract Factory模式中, 假设了飞机是由飞机导航系统, 飞机引擎组成的. 飞机的组成当然不是那么简单的, 涉及到很多东西.

对于用户而言, 他就是看到一架飞机在面前, 其可以感受得到的, 但是看这这架飞机, 并不能感受到这架飞机的制造过程(当然, 我也没必要知道飞机是怎么制造出来的, 我知道飞机怎么用就是了, 如果我使用飞机, 还需要知道飞机怎么制造的, 那太那个吧.).

 

所以飞机总工厂就研发的所有飞机的生产过程, 并要求各飞机工厂按照生产流程来做.

 

现在进一步复杂一下飞机的生产过程:

飞机有很多部件组成, 有飞机引擎, 导航系统, 机翼, 机身, 座位组成. 而且部件的生产, 组装有一定的顺序, 我必须先生产机身, 再生产飞机引擎, 把引擎安装到机身尾部, 再生产机翼, 安装到飞机机身上, 再生产座位, 安装到飞机机身里面, 然后就是导航系统的安装, 调试, 调试完成后试飞成功后. 这个飞机才算生产完成.(因为机身没有生产, 你就生产座位, 机翼等, 那就占用了地方, 所以这个生产过程的顺序要严格控制的).

 

这各生产过程是不是很复杂, 这里假设所有飞机的生产过程都是这样的.

 

作为用户的我, 我只需要知道飞机怎么用, 生产过程我不管.

 

这就是Builder 模式了:将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

把飞机这个复杂的对象的构建和它的表示分离(用户只管飞机怎么用, 不管生产过程)(用户只管飞机的表示, 不管飞机的构建), 而其他飞机的使用这个构建过程也可以生产出来..

 

角色

Directer类（1个）：定义复杂对象的构造过程, 调用Builder类的各个接口完成过程的构造.

Builder类：抽象类, 定义各种复杂对象Buider的接口.

各种复杂对象的Builder类（多个）：Builder类的子类, 实现Builder类的各个接口.

Product类: 具体的复杂对象类.

使用

我需要一架直升飞机, 我只要通知飞机总工厂, 飞机总工厂通知直升飞机厂生产直升飞机, 直升飞机厂按照总工厂定制的飞机生产流程生产直升飞机.

说明:

 

代码:

…

// 调用

     CHolicopterBuilder* pHolicopterBuilder = new CHolicopterBuilder;

     CPlaneDirector *pPlaneDirector = new CPlaneDirector(pHolicopterBuilder);

 

     // 创造飞机

     pPlaneDirector->ConstructPlane(pHolicopterBuilder);

 

     CHolicopter* pHolicopter = pHolicopterBuilder->GetHolicopter();

 

     pHolicopter->Fly();

看工程004Builder.rar

http://download.csdn.net/source/2837008

总结:

1.        Builder模式定义: 将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示.。

2.        说白了就是把一个复杂对象的构建与组成解耦.

3.  Director类负责该复杂过程的定制, 限定了对象的创建过程, 最终创建对象.

Builder类是对具体对象部件创建的抽象, 从而把复制对象部件创建实现留给具体的复杂对象创建类.

ConcreteBuuilder类就是具体复杂对象部件的创建类, 实现复杂对象部件的创建, 但由Director来控制.

Product类就是具体的复杂对象了, 它只保存了复杂对象的组成(部件), 属性等, 而不保存对象的创建过程.

 

Builder模式强调了对复杂的创建过程的控制. 所以

1. 需要生成的产品对象有复杂的内部结构时适用该模式。

2. 需要生成的产品对象的属性相互依赖，建造者模式可以强迫生成顺序, 例如各部件产生是有顺序的使用。

3. 当复杂对象的创建应该独立于该对象的组成部分和装配方式时使用.

4. 由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定。

毕竟, 把一个复杂的过程留给用户是危险的.

 

由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定。

如何应对这种变化？如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的变化，从而保持系统中的“稳定构建算法”不随着需求改变而改变？

变化点在哪里，封装哪里—— Builder模式主要在于应对“复杂对象各个部分”的频繁需求变动。其缺点在于难以应对“分步骤构建算法”的需求变动。

是的, 如果有两个创建过程, 那就需要两个Director了, 如果有10个, 100个, 那是不是太多Director类了?

 

对比Builder模式与Abstract Factory模式

既然Builder和Factory同属创建型模式，那么他们的最大共同点就在于都可以创建类对象，在这点上，不光这两个模式一样，其它创建型模式也一样.

Abstract Factory模式解决“系列对象”的需求变化，Builder模式解决“对象部分”的需求变化。

对于工厂模式来说，他创建后返回的，只能是玻璃，或者轮子，抑或是发动机。不管怎么样，他不能向客户返回一辆完整的汽车，要得到一辆完整的汽车，客户必须自己动手去把这些零部件组装成一辆汽车。而Builder 模式就把这个组装过程也给封装了.

对比两种模式的UML图可以理解到, Abstract Factory模式, 可以创建一件一件的东西, 但各件东西之间的创建关系, 并没有体现出来.

而Builder模式把这个"各件东西之间的创建关系"体现出来了, 封装到Director中.

 

其实两种模式的侧重点不同, 看下图

 

红色部分是两种模式相同(相似)的地方, 都有专门用于创建对象的类(Factory和Builder), 而且都抽象了出来, 把实现留给具体的类.

绿色部分是Builder模式比Abstract Factory模式多(好)的一个部分(), 就是把复杂对象的创建过程封装了并抽象了出来, 而Abstract Factory模式是没有的.

蓝色部分是Abstract Factory模式比Builder模式好的一个部分, Abstract Factory把具体的产品也抽象了, 按照系列来分类.

而Builder模式没有把产品抽象, 也没有把组件抽象(产品由组件组成). 可以这么理解在Abstract Factory模式中的产品就是Builder模式中的组件.

 

尝试把红, 绿, 蓝3个部分结合. 其实各个模式侧重的是它们的优点, 把各个模式的优点结合, 这才是运用, 而不要独立看各个模式或者比较那个模式更好.

符合需求的就是最好的.

 

另外, Builder模式通常和Composite模式组合使用。

项目应用

在我的热敏打印机例子中, 打印机对象的创建并没有设置复杂的创建过程或者组件之间有什么约束, 所以也没有硬生生的套进Builder模式中.

总之, Builder模式的核心就是: 要把对象的复杂的创建过程与对象的组成进行分离.

在网上说明的那些例子中, 那些创建过程一般都是比较简单的, 所以让人感觉Builder模式与Abstract Factory模式或者其他创造型模式区别不大.

引用:

http://www.souzz.net/html/edu/net/net1/38993.html

http://ldjsyl.javaeye.com/blog/190388

http://dev.csdn.net/htmls/14/14780.html