工厂模式允许您一次创建一个对象，而生成器模式允许您中断对象的创建过程。这样，您可以在创建对象期间添加不同的功能。

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

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

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

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

我相信，当您处理相同的代码库和不断变化的需求时，在一定的时间段内，Factory&Builder模式的用法和它们之间的区别可以更容易理解/澄清。

根据我的经验，通常从Factory模式开始，包括两个静态创建者方法，主要隐藏相对复杂的初始化逻辑。随着对象层次结构变得越来越复杂（或添加更多类型、参数），您可能最终会使用更多参数填充方法，更不用说您必须重新编译Factory模块。所有这些都会增加创建者方法的复杂性，降低可读性，并使创建模块更加脆弱。

该点可能是过渡/延伸点。通过这样做，您可以围绕构造参数创建一个包装器模块，然后您可以通过添加更多抽象（可能）和实现来表示新的（类似的）对象，而无需接触实际的创建逻辑。所以你有了“不那么复杂”的逻辑。

坦率地说，提到某种“一步或多步创建一个对象是不同的”，因为唯一的多样性因素不足以让我区分它们，因为我可以对我目前面临的几乎所有情况都使用这两种方法，而没有任何益处。这就是我最后想到的。

构建模式强调创建对象的复杂性（通过“步骤”解决）

抽象模式强调（多个但相关的）对象的“抽象”。

伸缩构造器模式

类比：

工厂：考虑一家餐馆。创建“今天的饭”是一种工厂模式，因为你告诉厨房“给我今天的饭吃”，厨房（工厂）根据隐藏的标准决定生成什么对象。生成器：如果您订购自定义披萨，则会显示生成器。在这种情况下，服务员告诉厨师（构建者）“我需要一个比萨饼；在其中添加奶酪、洋葱和培根！”因此，构建者公开了生成对象应该具有的属性，但隐藏了如何设置这些属性。

礼貌

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

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