设计模式之BUILDER（生成器）—对象创建型模式

1. 意图

        将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

2. 动机

        一个RT F（Rich Text Format）文档交换格式的阅读器应能将RT F转换为多种正文格式该阅读器可以将RT F文档转换成普通A S C I I文本或转换成一个能以交互方式编辑的正文窗口组件。但问题在于可能转换的数目是无限的。因此要能够很容易实现新的转换的增加，同时却不改变RT F阅读器。

        一个解决办法是用一个可以将RT F转换成另一种正文表示的Te x t C o n v e r t e r对象配置这个RT F R e a d e r类。当RT F R e a d e r对RT F文档进行语法分析时，它使用Te x t C o n v e r t e r去做转换。无论何时RT F R e a d e r识别了一个RT F标记（或是普通正文或是一个RT F控制字），它都发送一个请求给Te x t C o n v e r t e r去转换这个标记。Te x t C o n v e r t e r对象负责进行数据转换以及用特定格式表示该标记，如下图所示。

        Te x t C o n v e r t的子类对不同转换和不同格式进行特殊处理。例如，一个A S C I I C o n v e r t e r只负责转换普通文本，而忽略其他转换请求。另一方面，一个Te X C o n v e r t e r将会为实现对所有请求的操作，以便生成一个获取正文中所有风格信息的T E X表示。一个Te x t Wi d g e t C o n v e r t e r将生成一个复杂的用户界面对象以便用户浏览和编辑正文。

        每种转换器类将创建和装配一个复杂对象的机制隐含在抽象接口的后面。转换器独立于阅读器，阅读器负责对一个RT F文档进行语法分析。

        B u i l d e r模式描述了所有这些关系。每一个转换器类在该模式中被称为生成器（ b u i l d e r），而阅读器则称为导向器（ d i r e c t o r）。在上面的例子中， B u i l d e r模式将分析文本格式的算法（即RT F文档的语法分析程序）与描述怎样创建和表示一个转换后格式的算法分离开来。这使我们可以重用RT F R e a d e r的语法分析算法，根据RT F文档创建不同的正文表示—仅需使用不同的Te x t C o n v e r t e r的子类配置该RT F R e a d e r即可。

3. 适用性

        在以下情况使用B u i l d e r模式

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

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

4. 结构

        此模式结构如下页上图所示。

5. 参与者

• B u i l d e r（Te x t C o n v e r t e r）

— 为创建一个P r o d u c t对象的各个部件指定抽象接口。

• C o n c r e t e B u i l d e r（A S C I I C o n v e r t e r、Te X C o n v e r t e r、Te x t Wi d g e t C o n v e r t e r）

— 实现B u i l d e r的接口以构造和装配该产品的各个部件。

— 定义并明确它所创建的表示。

— 提供一个检索产品的接口（例如， G e t A S C I I Te x t和G e t Te x t Wi d g e t）。

• Director（RT F R e a d e r）

— 构造一个使用B u i l d e r接口的对象。

• P r o d u c t（A S C I I Te x t、Te X Te x t、Te x t Wi d g e t）

— 表示被构造的复杂对象。C o n c r e t e B u i l d e r创建该产品的内部表示并定义它的装配过程。

— 包含定义组成部件的类，包括将这些部件装配成最终产品的接口。

6. 协作

• 客户创建D i r e c t o r对象，并用它所想要的B u i l d e r对象进行配置。

• 一旦产品部件被生成，导向器就会通知生成器。

• 生成器处理导向器的请求，并将部件添加到该产品中。

• 客户从生成器中检索产品。

        下面的交互图说明了B u i l d e r和D i r e c t o r是如何与一个客户协作的。

7. 效果

        这里是B u i l d e r模式的主要效果：

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

        2) 它将构造代码和表示代码分开B u i l d e r模式通过封装一个复杂对象的创建和表示方式提高了对象的模块性。客户不需要知道定义产品内部结构的类的所有信息；这些类是不出现在B u i l d e r接口中的。每个C o n c r e t e B u i l d e r包含了创建和装配一个特定产品的所有代码。这些代码只需要写一次；然后不同的D i r e c t o r可以复用它以在相同部件集合的基础上构作不同的P r o d u c t。在前面的RT F例子中，我们可以为RT F格式以外的格式定义一个阅读器，比如一个S G M L R e a d e r，并使用相同的Te x t C o n v e r t e r生成S G M L文档的A S C I I Te x t、Te X Te x t和Te x t Wi d g e t译本。

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

8. 实现

        通常有一个抽象的B u i l d e r类为导向者可能要求创建的每一个构件定义一个操作。这些操作缺省情况下什么都不做。一个C o n c r e t e B u i l d e r类对它有兴趣创建的构件重定义这些操作。

        这里是其他一些要考虑的实现问题：

        1) 装配和构造接口生成器逐步的构造它们的产品。因此B u i l d e r类接口必须足够普遍，以便为各种类型的具体生成器构造产品。

        一个关键的设计问题在于构造和装配过程的模型。构造请求的结果只是被添加到产品中，通常这样的模型就已足够了。在RT F的例子中，生成器转换下一个标记并将它添加到它已经转换了的正文中。

        但有时你可能需要访问前面已经构造了的产品部件。我们在代码示例一节所给出的M a z e
例子中， M a z e B u i l d e r接口允许你在已经存在的房间之间增加一扇门。像语法分析树这样自底
向上构建的树型结构就是另一个例子。在这种情况下，生成器会将子结点返回给导向者，然
后导向者将它们回传给生成者去创建父结点。

        2) 为什么产品没有抽象类通常情况下，由具体生成器生成的产品，它们的表示相差是如此之大以至于给不同的产品以公共父类没有太大意思。在RT F例子中， A S C I I Te x t和Te x t Wi d g e t对象不太可能有公共接口，它们也不需要这样的接口。因为客户通常用合适的具体生成器来配置导向者，客户处于的位置使它知道B u i l d e r的哪一个具体子类被使用和能相应的处理它的产品。

        3 ) 在B u i l d e r中却省的方法为空C + +中，生成方法故意不声明为纯虚成员函数，而是把它们定义为空方法，这使客户只重定义他们所感兴趣的操作。

9. 代码示例

        我们将定义一个C r e a t e M a z e成员函数的变体，它以类M a z e B u i l d e r的一个生成器对象作为参数。
        M a z e B u i l d e r类定义下面的接口来创建迷宫：

        该接口可以创建：1）迷宫。2）有一个特定房间号的房间。3）在有号码的房间之间的门。G e t M a z e操作返回这个迷宫给客户。M a z e B u i l d e r的子类将重定义这些操作，返回它们所创建的迷宫。

        M a z e B u i l d e r的所有建造迷宫的操作缺省时什么也不做。不将它们定义为纯虚函数是为了便于派生类只重定义它们所感兴趣的那些方法。

        用M a z e B u i l d e r接口，我们可以改变C r e a t e M a z e成员函数，以生成器作为它的参数。

        将这个C r e a t e M a z e版本与原来的相比，注意生成器是如何隐藏迷宫的内部表示的—即定义房间、门和墙壁的那些类—以及这些部件是如何组装成最终的迷宫的。有人可能猜测到有一些类是用来表示房间和门的，但没有迹象显示哪个类是用来表示墙壁的。这就使得改变一个迷宫的表示方式要容易一些，因为所有M a z e B u i l d e r的客户都不需要被改变。

        像其他创建型模式一样， B u i l d e r模式封装了对象是如何被创建的，在这个例子中是通过M a z e B u i l d e r所定义的接口来封装的。这就意味着我们可以重用M a z e B u i l d e r来创建不同种类的迷宫。C r e a t e C o m p l e x M a z e操作给出了一个例子：

        注意M a z e B u i l d e r自己并不创建迷宫；它的主要目的仅仅是为创建迷宫定义一个接口。它主要为方便起见定义一些空的实现。M a z e B u i l d e r的子类做实际工作。

        子类S t a n d a r d M a z e B u i l d e r是一个创建简单迷宫的实现。它将它正在创建的迷宫放在变量_ c u r r e n t M a z e中。

        C o m m o n Wa l l是一个功能性操作，它决定两个房间之间的公共墙壁的方位。
        S t a n d a r d M a z e B u i l d e r的构造器只初始化了_ c u r r e n t M a z e。

        B u i l d M a z e实例化一个M a z e，它将被其他操作装配并最终返回给客户（通过G e t M a z e）。

        B u i l d R o o m操作创建一个房间并建造它周围的墙壁：

        为建造一扇两个房间之间的门， S t a n d a r d M a z e B u i l d e r查找迷宫中的这两个房间并找到它们相邻的墙：

        客户现在可以用C r e a t e M a z e和S t a n d a r d M a z e B u i l d e r来创建一个迷宫：

        我们本可以将所有的S t a n d a r d M a z e B u i l d e r操作放在M a z e中并让每一个M a z e创建它自身。但将M a z e变得小一些使得它能更容易被理解和修改，而且S t a n d a r d M a z e B u i l d e r易于从M a z e中分离。更重要的是，将两者分离使得你可以有多种M a z e B u i l d e r，每一种使用不同的房间、墙壁和门的类。

        一个更特殊的M a z e B u i l d e r是C o u n t i n g M a z e B u i l d e r。这个生成器根本不创建迷宫；它仅仅
对已被创建的不同种类的构件进行计数。

        构造器初始化该计数器，而重定义了的M a z e B u i l d e r操作只是相应的增加计数。

        下面是一个客户可能怎样使用C o u n t i n g M a z e B u i l d e r：

10. 已知应用

        RT F转换器应用来自E T + + [ W G M 8 8 ]。它的正文生成模块使用一个生成器处理以RT F格式存储的正文。
        生成器在S m a l l t a l k - 8 0 [ P a r 9 0 ]中是一个通用的模式：

• 编译子系统中的P a r s e r类是一个D i r e c t o r，它以一个P r o g r a m N o d e B u i l d e r对象作为参数。每当P a r s e r对象识别出一个语法结构时，它就通知它的P r o g r a m N o d e B u i l d e r对象。当这个语法分析器做完时，它向该生成器请求它生成的语法分析树并将语法分析树返回给客户。

• C l a s s B u i l d e r是一个生成器， C l a s s使用它为自己创建子类。在这个例子中，一个C l a s s既是D i r e c t o r也是P r o d u c t。

• B y t e C o d e S t r e a m 是一个生成器，它将一个被编译了的方法创建为字节数组。B y t e C o d e S t r e a m不是B u i l d e r模式的标准使用，因为它生成的复杂对象被编码为一个字节数组，而不是正常的S m a l l t a l k对象。但B y t e C o d e S t r e a m的接口是一个典型的生成器，而且将很容易用一个将程序表示为复合对象的不同的类来替换B y t e C o d e S t r e a m。

        自适应通讯环境（ Adaptive Communications Environment ）中的服务配置者（ S e r v i c e C o n f i g u r a t o r）框架使用生成器来构造运行时刻动态连接到服务器的网络服务构件[ S S 9 4 ]。这些构件使用一个被L A L R（1）语法分析器进行语法分析的配置语言来描述。这个语法分析器的语义动作对将信息加载给服务构件的生成器进行操作。在这个例子中，语法分析器就是D i r e c t o r。

11. 相关模式

        Abstract Factory （3 . 1）与B u i l d e r相似，因为它也可以创建复杂对象。主要的区别是B u i l d e r模式着重于一步步构造一个复杂对象。而Abstract Factory着重于多个系列的产品对象（简单的或是复杂的）。B u i l d e r在最后的一步返回产品，而对于Abstract Factory来说，产品是立即返回的。

        C o m p o s i t e（4 . 3）通常是用B u i l d e r生成的。

 

 

 

转载请注明出处！！！

http://blog.csdn.net/stuqbx