生成器和抽象工厂生成器设计模式在某种程度上与抽象工厂模式非常相似。这就是为什么在使用其中一种或另一种情况时，能够区分不同的情况是很重要的。在抽象工厂的情况下，客户端使用工厂的方法来创建自己的对象。在Builder的例子中，Builder类被指示如何创建对象，然后被要求创建对象，但是类的组合方式取决于Builder类，这一细节决定了两种模式之间的区别。产品通用接口在实践中，由混凝土建设者创建的产品具有明显不同的结构，因此如果没有理由派生不同的产品，则生成一个公共的父类。这也将生成器模式与抽象工厂模式区分开来，抽象工厂模式创建从公共类型派生的对象。

发件人：http://www.oodesign.com/builder-pattern.html

生成器和抽象工厂生成器设计模式在某种程度上与抽象工厂模式非常相似。这就是为什么在使用其中一种或另一种情况时，能够区分不同的情况是很重要的。在抽象工厂的情况下，客户端使用工厂的方法来创建自己的对象。在Builder的例子中，Builder类被指示如何创建对象，然后被要求创建对象，但是类的组合方式取决于Builder类，这一细节决定了两种模式之间的区别。产品通用接口在实践中，由混凝土建设者创建的产品具有明显不同的结构，因此如果没有理由派生不同的产品，则生成一个公共的父类。这也将生成器模式与抽象工厂模式区分开来，抽象工厂模式创建从公共类型派生的对象。

发件人：http://www.oodesign.com/builder-pattern.html

逐步构建复杂对象：构建器模式通过使用单一方法创建一个简单对象：工厂方法模式使用多工厂方法创建对象：抽象工厂模式

许多设计从使用工厂方法开始（不太复杂，通过子类更可定制），并向抽象工厂、原型或生成器（更灵活，但更复杂）发展。

Builder专注于逐步构建复杂对象。

实施：

明确定义构建所有可用产品表示的通用构建步骤。否则，您将无法继续实现该模式。在基本生成器接口中声明这些步骤。为每个产品表示创建一个具体的生成器类，并实现它们的构造步骤。

抽象工厂专门创建相关对象的族。Abstract Factory会立即返回产品，而Builder允许您在获取产品之前运行一些额外的构建步骤。

您可以将抽象工厂与Bridge一起使用。当Bridge定义的某些抽象只能用于特定实现时，这种配对非常有用。在这种情况下，抽象工厂可以封装这些关系，并从客户端代码中隐藏复杂性。

深入设计模式

这两种模式都有相同的必要性：对某些客户端代码隐藏复杂对象的构造逻辑。但是，是什么使一个对象变得“复杂”（或有时变得复杂）？主要是由于依赖关系，或者更确切地说是由更多部分状态组成的对象的状态。您可以通过构造函数注入依赖项来设置初始对象状态，但一个对象可能需要很多依赖项，其中一些依赖项将处于默认初始状态（只是因为我们应该了解到，将默认依赖项设置为null不是最干净的方式），而另一些依赖项则设置为由某种条件驱动的状态。此外，有些对象财产是某种“不经意的依赖关系”，但它们也可以假定为可选状态。

有两种众所周知的方法来控制这种复杂性：

组合/聚合：构造一个对象，构造其依赖对象，然后连接在一起。在这里，构建器可以使确定引导组件构建的规则的过程透明而灵活。多态性：构造规则直接声明到子类型定义中，因此每个子类型都有一组规则，某些条件决定了这些规则中的哪一个适用于构造对象。工厂完全适合这种情况。

没有什么可以阻止这两种方法的混合。一个产品系列可以抽象对象创建，由生成器完成，生成器可以使用工厂来确定实例化哪个组件对象。

复杂构造是指要构造的对象由抽象表示的不同的其他对象组成。

考虑麦当劳的菜单。菜单包括饮料、主菜和配菜。根据单个抽象的后代组合在一起，创建的菜单具有另一种表示。

例如：可乐、巨无霸、薯条示例：雪碧、掘金、卷曲薯条

在那里，我们得到了两个具有不同表示的菜单实例。施工过程保持不变。您可以创建一个菜单，其中包含饮料、主菜单和副菜单。

通过使用生成器模式，可以将创建复杂对象的算法与用于创建它的不同组件分开。

就构建器模式而言，算法封装在控制器中，而构建器用于创建完整的部分。在控制器的算法中改变使用的生成器会导致不同的表示，因为其他部分都是由菜单组成的。菜单的创建方式保持不变。