在说明生成器模式之前，不得不说一说它和抽象工厂模式的区别：两者看起来很相似，都是应对一系列“对象”的变化，而抽象出一个公共接口。不同处在于抽象工程所要创建的一系列对象尽管是相关的，但各自是各自，他们之间的具体应用关系由客户决定；而生成器模式对应的一系列对象是在一个“大对象”下的必要组成部分，也就是说，我们关心的是要得到一个“大对象”，而抽象工厂所关心的是要得到一系列对象。另一个显著的区别是，抽象工厂模式得到一系列对象的使用“算法”由用户决定，而生成器模式是用固定的算法组织生成的一系列子对象，来生成一个所要的对象。

     回归到生成器模式上来，先说动机（也就是要用模式的原因）

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

     上述原因说出了变化，和不变。和抽象工厂的动机比较，我们会发现多出来了“固定算法”和“要得到的是一个复杂的大对象”。既然是这样，我们就可以再定义一个组织者类，来描述算法，我们还是用抽象工厂封装变化部分。鉴于我们要得到的并不是子对象，所以只需要对外发布一个生成大对象的方法就是了。

      因为还未实际使用过该模式，所以说对这个“用算法构成大对象”，具体应该是个什么样，还缺乏感性认识。

     再琢磨一下GoF的定义：
 
     将一个负责对象的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。

           ————GoF

     哦，忘了说缺点了，如果固定的算法不再固定，就不能应用该模式。确切的说所有的模式共有的缺点就是，当假设不变的部分发生了变化，该模式就不适用。

     探讨：将固定算法放在抽象build接口内可不可以呢？