Builder模式（建造者模式 创建型）

GoF说，在两种情况下适合使用Builder模式：

1）当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。

2）当构造过程必须允许被构造的对象有不同的表示时。

硬咬着文字去解读，是很难理解的，要容易理解可以用类比、图例的手法，加快理解这个模式。

举个栗子：

Director是设计工程师，他设计了房子要先建地基、二建主体、三建砖墙。然后交给工人去建造。

工人A去建造，A建造的房子是大厦，所以地基是用打桩的形式建的，主体是用大钢筋强水泥建的。墙是用空心砖建的。

工人B去建造，B建造的房子是民房（大概3层），所以地基是挖地基的方式，主体是用小钢筋普通水泥建的，墙是用红心砖建的。

工人C去建造，C建造的房子是毛坯房，毛坯房需要打地基？不打。毛坯房也没有主体，因为不盖楼。墙就用普通的砖头建造。

我是顾客，我选择B去建房子，然后要求Director帮我监督，然后再从B那里取出房子。

这整个流程就是builder模式的实现过程。

工人A，B，C都是Builder，都属于建筑工人：Abstract Builder，他们就做3件事：打地基、建主体还有建砖墙。Builder只对他需要做的部分，给做好，做出特色，其余不需要做的（例如对毛坯房来说不需要建地基），那它就空置。他是工人，只专注于把事情做好就行，方向上的事情是领导安排。

建房子的步骤有先后顺序，是一套算法，这交给Director去实现，由他规行为的先后顺序，他只做监督，不做事情。

就这样，Builder模式实现了算法，与实现的分离。Director专注于算法，而Builder专注于实现，责任分明。

在这里得上个图，更好的去理解一下

简单讲述下流程：顾客（main）选择工人B（BuilderB）去建房子（AbstractBuild* Bbud = new BuildB()），然后派Director去监督（Director->GetBuilder(Bbud)），在指导的过程中，Director按照它的想法，要求Bbud先打地基（AbstractBuilder->productPartX()）,再做主体（AbstrctBuilder->productPartY()）,最后砌墙（AbstractBuilder->productPartZ() ），顺利完成监督任务。

最后要拿回房子了，Client找工人B拿回房子（Bbud->GetProduct()）。

Builder模式的效果（借用GoF的描述）：

1 )它使你可以改变一个产品的内部表示。Builder对象提供给导向器一个构造产品的抽象接口。该接口使得生成器可以隐藏这个产品的表示和内部结构。它同时也隐藏了该产品是如何装配的。因为产品是通过抽象接口构造的，你在改变该产品的内部表示时所要做的只是定义一个新的生成器。

2) 它将构造代码和表示代码分开。Builder模式通过封装一个复杂对象的创建和表示方式提高了对象的模块性。客户不需要知道定义产品内部结构的类的所有信息；这些类是不出现在Builder接口中的。每个Builder子类包含了创建和装配一个特定产品的所有代码。这些代码只需要写一次；然后不同的Director可以复用它以在相同部件集合的基础上构作不同的Product。

3 )它使你可对构造过程进行更精细的控制。Builder模式与一下子就生成产品的创建型模式不同，它是在导向者（Director）的控制下一步一步构造产品的。仅当该产品完成时导向者才从生成器中取回它。因此Builder接口相比其他创建型模式能更好的反映产品的构造过程。这使你可以更精细的控制构建过程，从而能更精细的控制所得产品的内部结构。

--关于builder模式，我对比了好几种对builder模式的解释，发现每个人的理解都不一样，比较难着手。而后看了GoF的原著，才了解到其基本的内涵。之前参照过的对Builder的几种解释，是别人基于对GoF的理解后，扩展出来的想法。究竟哪种是标准的Builder设计模式？哈哈，倒也不必如此纠结，重要的是在探索中我们学会了从多个角度去分析解决问题，灵活对待问题。