建造者模式
通常我们在建造一个物体的时候，会先建造每一个部分，再分阶段将他们组装起来。这种用于组装具有复杂结构的实例的模式就是 Builder 模式。
Builder 模式中登场的角色
- Builder（建造者）： Builder 角色负责定义用于生成实例的接口（API）。Buider角色中准备了用于生成实例的方法。
ConcreteBuilder（具体的建造者）： ConcreteBuilder 角色负责实现 Builder 角色的接口的类（API）。这里定义了在生成实例时实际被调用的方法。此外，在
ConcreteBuilder 角色中还定义了获取最终生成结果的方法。
Director（监工）： Director 角色负责使用 Builder 角色的接口（API）来生成实例。它并不依赖于 ConcreteBuilder 角色。它只负责调用在
Builder 角色中被定义的方法。
- Client（使用者）： Client 角色使用了 Builder 模式。
- 示例代码
- Builder 模式类图
- Builder 模式时序图
拓展
谁知道什么？
我们的 Main 类不知道（没有调用 Builder 类）只是调用 Director 类的 construct 方法，而 Director 类也不知道真正使用的类，他只知道我使用了
Builder 类的子类，他们都实现了 Builder 类定义的方法。因此我们就可以随意替换子类，组件才具有高价值
设计能解决的事情和不能决定的事情
在 Builder 角色中我们需要声明实现功能的必须方法，Director 角色中去决定方法的调用方式、顺序。因此 Builder
类中所定义的方法至关重要。假设我们目前实现了 两种 ConcreteBuilder 但是我们在新的需求里又增加了新的 ConceteBuilder
我们是否可以使用相同的方法模板来实现这个类？因此我们设计类的时候要尽可能的使类中的方法灵活的应对近期的变化。
相关的设计模式
- Template Method 模式： 在 Builder 模式中，Director 角色控制 Builder 角色。在 Template Method 模式中，父类控制子类。
- Composite 模式： 有些情况下 Builder 模式生成的实例构成了 Composite 模式。
- Abstract Factory 模式： Builder 模式和 Abstract Factory 模式都用于生成复杂的实例。
-
Facade 模式： 在 Builder 模式中，Director 角色通过组合 Builder 角色中的复杂方法向外界提供可以简单生成实例的接口（API）。在
Facade 模式中的 Facade 角色则通过组合内部模块向外部提供可以调用的接口（API）。