设计模式-建立型-生成器模式（BUILDER）

咱们先看看gof对生成器模式的结构描述。

　　值得注意的是跟工厂方法模式同样的，生成器模式也引入了一个新的抽象，不过这个抽象的名字是builder。咱们能够在这个结果上补全出工程方法模式的结构（以下图）。正如图书所示，用client替代Director，增长一个product抽象类，去掉ConcreteBuilder中的getResult方法，这就是一个典型的工厂方法模式的结构图。须要注意一点的是builder模式与工厂方法模式除了在这点相似其余的地方没有任何相似的地方。我增长这个图的目的不是为了让读者困惑而是想表达模式与模式之间比较容易混淆，在学习一个模式的时候要注意追寻一个模式的根本需求而不是浮于一些例子的表面。至于怎么作？笔者的经验，把gof的书读上n遍，一些东西就天然开朗了。固然能笔者的博客能帮到你那就更好了。^_^

　　咱们继续来讨论生成器模式。在gof的书中对于生成器模式是这样描述的。

　　“将一个复杂对象的构建与它的表示分离，使得一样的构建过程能够建立不一样的表示。”

　　咱们使用书中的例子来举例。

　　

　　关于生成者模式的定义首先吸引咱们的是该对象是复杂对象，构建这个复杂对象可能须要不少步骤。那么什么是复杂对象的构建与它的表示呢？ 就上面的结构图，笔者的理解是ASCIIText，TeXText，TextWidget这三个对象就是定义中所说的复杂对象。复杂对象的构建是什么呢？这里分两类，一类是复杂对象的构建步骤一类是复杂对象的构建实现。构建实现被封装在了ASCIIConverter，TeXConverter，TextWidgetConverter中。构造步骤则封装了RTFReader中，很明显这里的Converter就是builder角色，RTFReader就是director角色。他们一块儿构成了复杂对象的构建。那么什么事复杂对象的表示呢？ASCIIText，TeXText，TextWidget这三个对象是咱们要的结果，对结果的表示在builder角色中有一个成员方法GetResult。全部复杂对象的获取最后是经过builder类的成员函数的来获取的，这个成员函数自己就是对目的复杂对象的表示。因而咱们能够预期像下面同样的客户代码。

　　void getComplexObj()

　　{

　　　　RTFReader objReader;

　　　　objReader.setTextConvert(new ASCIIConverter());

　　　　objReader.setTextConvert(new TeXConverter());

　　　　objReader.setTextConvert(new TextWidgetConverter());

　　　　Text * result;

　　　　for each converter in objReader

　　　　{

　　　　　　objReader.ParseRTF();

　　　　　　result = objReader.getTextConvert()->getResult();

　　　　　　//...  operation about the complex object

　　　　}

　　}

固然笔者代码是不彻底的，笔者想说明的也仅仅是一样的构建方法是如何能有不一样的表示的。正如gof书中所说的那样生成器模式的重点在于一步一步构建出你想要的复杂对象，固然中间不可缺乏的是几个角色分别是：1.Director，它负责了指导对象如何一步一步被建立的。2.Builder它负责了建立对象的细节实现和保存对象的状态.3，最为重要的是客户不是从director获取这个复杂对象而是从Builder中获取，这样构建于表示分离了。这就是builder设计模式存在的目的。