工厂：用于创建对象的实例，其中对象的依赖项完全由工厂保存。对于抽象工厂模式，通常有许多相同抽象工厂的具体实现。工厂的正确实现是通过依赖注入注入的。

生成器：用于构建不可变对象，当要实例化的对象的依赖项部分是预先知道的，部分是由生成器的客户端提供的。

对于设计模式，通常没有适用于所有情况的“更有利”解决方案。这取决于您需要实施什么。

来自维基百科：

Builder专注于构建一步一步复杂的物体。摘要工厂强调产品系列对象（简单或复杂）。生成器将产品作为最终产品返回步骤，但就抽象而言工厂关心，产品得到立即返回。生成器通常构建一个复合。通常，设计开始时使用工厂方法（不那么复杂，更多可定制，子类激增）并向抽象工厂发展，原型或生成器（更灵活，更复杂）发现更灵活的地方需要。有时创造模式是互补的：构建者可以使用要实现的其他模式构建哪些组件。摘要工厂、建造商和原型可以使用Singleton实现。

工厂设计模式维基百科条目：http://en.wikipedia.org/wiki/Factory_method_pattern

构建器设计模式的维基百科条目：http://en.wikipedia.org/wiki/Builder_pattern

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

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

工厂模式在运行时创建一个类的具体实现，即它的主要目的是使用多态性来允许子类决定实例化哪个类。这意味着在编译时我们不知道将要创建的确切类，而Builder模式主要涉及解决伸缩构造函数反模式的问题，这是由于类的大量可选字段而产生的。在构建器模式中，没有多态性的概念，因为我们知道在编译时要构造什么对象。

这两种模式的唯一共同主题是在工厂方法和构建方法后面隐藏构造函数和对象创建，以改进对象构造。

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

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

实施：

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

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

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

深入设计模式

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

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

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

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