建造者模式

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

也就是说一个复杂的对象，各个部分变化，但是将他们组合在一起的算法比较稳定，这时候，我们应该采取什么机制去创建一个复杂的对象？

举个例子自行车就是‚一个复杂对象‛，它有车轮和车架组成，但不管车轮和车架这两个部件怎么变化，生产一辆自行车的过程是不会变的，即组装过程是不会变的。我们需要做的时候随着需求的变化，我们怎么生产这个复杂对象？我想要凤凰牌自行车，我想要永久牌的自行车的时候呢？

解决方案：建造者模式可以将一个产品的内部表象与产品的生成过程分割开来，从而可以使一个建造过程生成具有不同的内部表象的产品对象。

也就是说，需要创建一个Director对象，来指挥建立一个最后的复杂产品，Director通过实例化不同的具体Builder，完成不同的复杂产品。这些产品的建造过程都是相似的，所以我们每个具体的建造类，都是继承自一个抽象的建造类。对于每个具体建造类所需要的零件到底是什么，需要具体的建造类，去实例化每个零件产品。

举个例子，我是客户，我想买自行车，我必须实例化一个Builder对象，即要建造一个永久牌自行车，我还要实例化一个Director对象，然后告诉这个对象给我建造一个永久牌自行车，然后我就不管了，我通过调用DIrector对象的construct()方法就能获得一辆永久牌自行车。

对于Director的工作过程，在construct方法中通过调用永久牌自行车的建造过程，建造完之后，返回getResult。

对于建造永久牌自行车的过程，我必须有一个产品类。然后有很多零件，我通过建造的每一个步骤，对这个产品进行组装，最后返回这个对象，也就是永久牌自行车。

上面的图Builder和ConcreteBuilder都缺少了一个product属性。

Builder对应于组装自行车所使用的车轮和车架
 ConcreteBuiler1对应于永久牌车轮和车架，同时可以返回一辆永久牌自行车，ConcreteBuiler2对应于凤凰牌车轮和车架，同时可以返
回一辆凤凰牌自行车
 Product对应于自行车
Director表示组装过程。

前面我们说过的抽象工厂模式（Abtract Factory）解决系列对象的需求变化，Builder模式解决对象部分的需求变化，建造者模式常和组合模式（Composite 
Pattern）结合使用。

如果产品的内部变化复杂，可能会导致需要定义很多具体建造者类来实现这种变化，导致系统变得很庞大

应用实例：

在联机射击游戏中每一个游戏人物角色都需要提供一个完整的角色造型，包括人物造型、服装、武器等，如何创建一个完整的游戏角色？

审题:是创建一个角色，而这个角色是由很多部分组成的，而且部分是变化的。所以要采用Builder模式。

显然游戏人物是一个复杂的产品，需要很多零件，包括造型，服装，武器，但是每个游戏人物建造的过程都是相似的。

具体解决办法参考上图。很好设计的。