设计模式-创建型-生成器模式（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设计模式存在的目的。