|
|
意图：
将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示，而且实
际的创建方法和过程客户是不知道。通常意义上我们可以这样理解：我们需要创建一个复杂
的对象，但是提供给我们的是创建其中的一部分的操作，我们自己需要决定创建的各个部分
的数量、顺序和关系，然后最终通过一个方法得到最终的产品，而各个部分的具体的内容我
们不知道，是由我们选择的具体的创建者不同而不同的。
通俗的例子：
设想你是一个顾客，你上一个餐厅吃饭要点一桌饭菜，你要求的最终结果是一桌可口的饭菜，
而一桌饭菜由不同的部分构成（主食、酒水、热菜、冷菜、汤），而各个部分是否需要，需
要多少，上菜的顺序都是你自己可以控制的，最终你得到的是自己创建的一桌饭菜，而且这
桌饭菜的结果和你选择的餐厅是直接相关的（不同的餐厅对同一道菜的做法和用料可能是不
同的），而且这个菜是如何做出来的你也不知道。
参与者：
Client：就是顾客或者客户，例子中就是你
Builder：创建者，定义一些接口方法创建产品的各个部分以及得到最终的结果，例子中等价于服务员
ConcreteBuilder：具体创建者，就是真正生成产品的创建者，例子中就是具体的某个餐厅的厨师
Product：要创建的最终的产品，由多个复杂的子产品组成，例子中就是一桌饭菜
适用性：
1、创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式。
2、构造过程必须允许被构造的对象有不同的表示。
3、被构造的对象比较复杂，其组成部分的个数和组合方式随客户的要求差异比较大。
优点：
1、你可以自由的改变产品的内部表示，因为生成器隐藏了产品的表示和内容结构，同时也隐藏了产品是如何装配的，产品的创建都是通过抽象接口构造的。
2、构造代码和表示代码分离了。它通过封装一个复杂对象的创建和表示方式提高了对象的模块性，客户不需要知道定义产品内容结构的类的信息，它们是不出现在创建者接口中的。每个具体的创建者包含了创建和装配一个特定产品的所有代码，然后不同的客户就可以复用它们以在相同的部件集合的基础上构造不同的产品（仅仅是内容表示不同）
3、客户可以对构造过程进行更精细的控制，实际上产品部件的个数和结合方式都是由用户来控制的，其构造过程完全是由客户自己控制的。
缺点：
好像没有什么明显的缺点。
技巧：
1、一般情况下至少需要以下的方法接口：生成“空的”最终产品、生成子部件、得到最终产品，生成子部件的方法往往不会返回任何值，生成的子部件被直接添加到产品中了，其方式是由代码内容决定的。
2、产品不需要抽象类，特别是由于创建对象的算法复杂而导致使用此模式的情况下或者此模式应用于产品的生成过程，其最终结果可能差异很大，不大可能提炼出一个抽象产品类。
3、创建者中的创建子部件的接口方法不是抽象方法而是空方法，不进行任何操作，具体的创建者只需要覆盖需要的方法就可以，但是这也不是绝对的，特别是类似文本转换这种情况下，缺省的方法将输入原封不动的输出是合理的缺省操作。
|
|
