十、设计模式-构建器模式（Builder）

1、动机

      在软件系统中，有时候面临这“一个复杂对象”的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法相对稳定。

      如何应对这种变化呢？如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的变化，从而保持系统中的“稳定构建算法”不随着需求的改变而改变？

2、举例

      假设我们现在要建一个房子，初始化可能包括窗户、墙壁、门等各个部分的构建工作，如下图：

这里插个话题，有一点要注意：不可以把对象构建工作放在基类构造函数中，比如下面这样：

原因是违背了继承中多态原则。你看，House本身是一个基类，而this指向的是晚绑定的子类对象，而对象创建是先有基类再有子类，这里执行构造函数说明House还没有造出来，所以this是指不到子类上。

回到正确代码中，现在假设子类有石头房：

到现在，大概流程就完成了。现在我们想把构建House的init()工作分离出来，放到一个类中，init名字换成Construct：

我们把HouseDirector构造函数补充一下：

3、模式定义

      将一个复杂对象的构建与其表示相分离，使得同样的构建过程（稳定）可以创建不同的表示（变化）

4、结构图

5、要点总结

（1）Builder模式主要用于“分步骤构建一个复杂的对象”。在这其中，“分步骤”是一个稳定的算法，而复杂对象的各个部分则经常变化

（2）变化点在哪里就封装哪里——Builder模式主要在于“复杂对象的各个部分”的频繁需求变动。其缺点在于难以应对“分步骤构建算法”

（3）在Builder模式中，要注意不同语言中构造器内调用虚函数的差别（C#、JAVA中是可以在基类构造函数中创建子类，C++不行）