设计模式（二）：创建型模式—Builder（生成器）

一、定义

1.意图

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

2.结构图

这个是GoF原著里给出的结构图：

(https://www.processon.com/view/link/5abb908fe4b027675e449fe8)

下面这个是我理解的结构图：

(https://www.processon.com/view/link/5abb93c2e4b018c271d07eb7)

3.参与者

1）Builder：声明一个可以创建组成部件、获取最终产品的接口。

2）ConcreteBuilder：实现Builder接口，定义并明确自身所创建的表示。

3）Director：构造一个使用Builder接口的对象。

4）Product：被构造的复杂对象，也包括组成部件所属的类。

二、解决的问题

存在这样一个场景，Client需要一个复杂对象ComplexObject，一个复杂对象ComplexObject由简单对象SimpleObjectA、SimpleObjectB和SimpleObjectC组成，存在多种可能的ComplexObject，并且不同的ComplexObject由不同种类的SimpleObjectA、B、C组成，除此之外，即使是同一种ComplexObject，它所需要的每种组成部件的数量也可能有所不同，因此，具体的装配过程应该由Client来控制。

也就是说，我们面临的问题是，需要创建一个由多个简单对象组成的复杂对象，该复杂对象可能有多种不同的表示，即该组成该对象的部件可能有所不同，还有一点就是，装配到该对象上的组建数目是不确定的，需要由客户来控制。

这时候如果使用抽象工厂模式，因为需要由Client控制具体的装配过程，因此不能再使用工厂封装ComplexObject的创建过程，那么就只能由工厂创建部件，再由Client使用这些部件组装出ComplexObject，但是Client所要使用的其实只有ComplexObject，所以这时候产生的Client与部件间的耦合是不必要的。

三、效果

使用Builder后，一是可以方便的改变产品的内部表示，只需要添加一个新的ConcreteBuilder即可；二是Builder封装了部件的创建代码，客户不需要了解组件所属的类，只需要使用Builder提供的接口，即可添加一个部件到产品中，而且客户只要了解复杂对象的接口即可进行使用，而不需要知道具体的类，这样耦合就降低了；三是客户可以更精细地控制产品的装配过程。

四、适用性

书里给出的是：

1）当创建复杂对象的算法应该独立于该对象的组成部分以及他们的装配方式时；

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

五、缺点

产品中有新部件加入或已有部件发生变化时需要对每个ConcreteBuilder进行修改，有可能造成维护困难。