转自大话设计模式：
part1：画一个游戏里面的小人，要求有头，有身体，有2手，2脚。
颜色类:
钢笔类：
//制图类:
测试1: 如果我要画2个不同的人，一个胖子一个瘦子，但是都有相同的部位，因为有可能遗忘，所以导致第二个实例化对象缺胳膊少腿。显然是不符合的。part2进行改进
part2: 将一个复杂的对象的建造过程与他的表示进行分离，使得同样的构建过程可以创造出不同的表现。
1：将建造的过程稳定住，进行抽象，避免被遗忘
2、
因为不管瘦子还是胖子都会有这个构建过程，所以直接用瘦子和胖子类继承上面的抽象类，并且重写建造过程中的具体实现。
3、但是我们如果在客户端进行调用的时候，依然是要去知道这个胖子或者瘦子的具体实现方法。并没有彻底解决问题(因为重写过程中，也有可能忘记去实现具体的方法)。所以建造者模式中很重要的 指挥者类即将登场。
指挥者内部去调用建造者的建造过程。见下面的 createPerson
这样我们客户端在调用的时候就可以隔离用户与建造过程的关联。
4、模拟客户端调用：
例子总结： 实际过程中，比如还有很多小细节，比如 眼睛 眉毛 鼻子等，如果是每个具体的小人都必须要有的，则可以加入到我们的建造过程中，反之，没有必要。 建造者模式就是逐步构建产品。所以Builder里面的方法要足够普遍，以便为各种类型的建造者构造。
建造者模式结构图: 上面的例子中 最后画出来的人就是具体的产品
part3:
产品类:最后的的成品
//建造过程的抽象类:
//具体的建造者A
//具体建造者B
指挥者: 不能少了我们非常重要的指挥者，让客户端的调用 完全隔离掉建造过程与最后的表示。
//模拟客户端调用:
抽象类 Builder 类找到对应的实例化的类,ConcreateBuilderA, 因为ConcreateBuilderA里面是实现了抽象类中的方法的，相当于在这个构建过程中，A是去做了事情的。 然后在实例化指挥者的时候，传入抽象类的引用，进行调用抽象类的构建过程，相当于客户端不需要去管理具体的建造过程，只需要调用指挥者就行了。 p1.show(). 展示给我们看了 product里面是添加了部件A和部件B的。
建造者模式总结：
定义: 将一个复杂对象的构建过程与他的表示进行分离，使得同样的构建过程可以创建不同的表示,使用了建造者模式，用户只需指定需要建造的类型就可以得到他们，而具体的建造过程和细节，用户就无需关心了。
Builder相当于就是 : 构建一个小人各个部分的抽象类， 为创建一个product对象的各个部件指定的的抽象接口。
ConcreateBuilder: 具体的小人，具体实现如何画出小人的身体的各个部分。 是具体建造者，实现builder接口，构造和装配各个部件，
product： 指那些具体的小人，
director:指挥者，实例化出来的对象，用于使用builder的接口。
使用建造者模式的时候：
用于创建一些复杂对象，这些对象内部构建的顺序通常是稳定的，但是建造内部通常会面临很多的变化(指的是方法内部)
好处就是 使用建造者模式把 建造代码与显示代码进行分离，由于建造者隐藏了该产品是如何组装的，所以需要改变一个产品的内部表示，只需要再定义一个具体的建造者就可以了。
当创建复杂对象的算法应该独立于该对象的组成部分以及他们的装配方式时使用的模式。