实现
  通常有一个抽象的Builder类为导向者可能要求创建的每一个构件定义一个操作。这些操作缺省情况下什么都不做。一个ConcreteBuilder类对它有兴趣创建的构件重定义这些操作。   还是那句话，这并不是Builder模式的专利，只要有抽象/具象关系就是这样。   这里是其他一些要考虑的实现问题：
1) 装配和构造接口  生成器逐步的构造它们的产品。因此Builder类接口必须足够普遍，以便为各种类型的具体生成器构造产品。   这一点在前一篇文章中也提过，足够普遍的意思是它足够各个具象类生成各自的产品。
一个关键的设计问题在于构造和装配过程的模型。构造请求的结果只是被添加到产品中，通常这样的模型就已足够了。在RTF的例子中，生成器转换下一个标记并将它添加到它已经转换了的正文中。
但有时你可能需要访问前面已经构造了的产品部件。我们在代码示例一节所给出的Maze例子中，MazeBuilder接口允许你在已经存在的房间之间增加一扇门。像语法分析树这样自底向上构建的树型结构就是另一个例子。在这种情况下，生成器会将子结点返回给导向者，然后导向者将它们回传给生成者去创建父结点。   这段话想表达的是有时需要将创建的节点返回给Director以便进行更精细的控制。我们无法找到语法分析树中使用Builder模式的例子，所以编写了下面构建菜单的例子。首先是抽象类：   buildMenu和buildItem分别返回各自构建的节点，以便在addItem中使用。   有一点需要注意的是，代码中返回的节点的指针类型均为void*。这是因为不同的具象Builder生成的节点类型之间一般是毫无关联的。另外一点，Director其实也不需要知道这些细节。   接下来看示例。假设有以下Menu和MenuItem类。     我们可以这样实现生成菜单的Builder：     然后就可以像下面这样编写代码：     程序执行结果如下：     我们得到了一个简单的菜单。   同样地，我们也可以另外实现一个生成测试脚本的Builder。     这里的MenuTester,ItemCheck和前面的Menu、MenuItem没有任何关系。 比较这两个Builder的实现也可以发现：抽象的行为一样，具象的行为完全不同。   利用者侧的代码也几乎一样：     这里的buildTest和前一段代码中的buildTest是同一个函数。   这段代码的执行结果为：     内容是一连串的测试动作。   利用者只要使用不同的具象Builder，就可以在毫不知情的情况下构建完全不同的产品。   作者观点   可以这样理解Builder模式：相同的套路，构建不同的产品。   注：   本文中蓝 {MOD}粗体文字都引自《设计模式》一书。   觉得本文有帮助？请分享给更多人。 阅读更多更新文章，请扫描下面二维码，关注微信公众号【面向对象思考】