Builder设计模式和Factory设计模式之间的区别是什么?

哪一种更有利?为什么?

如果我想测试和比较/对比这些模式,我如何将我的发现表示为图表?


当前回答

抽象工厂和生成器模式都是创造性模式,但目的不同。

抽象工厂模式强调为相关对象族创建对象,其中:

每个族都是从公共基类/接口派生的一组类。每个对象都会作为一次调用的结果立即返回。

构建器模式侧重于一步一步地构建一个复杂的对象。它将表示与构造复杂对象的过程解耦,以便相同的构造过程可以用于不同的表示。

Builder对象封装了复杂对象的配置。Director对象知道使用Builder的协议,其中协议定义了构建复杂对象所需的所有逻辑步骤。

其他回答

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

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

生成器和抽象工厂有着不同的目的。根据正确的用例,您必须选择合适的设计模式。

生成器的显著特点:

生成器模式使用简单对象和分步方法构建复杂对象生成器类逐步构建最终对象。此生成器独立于其他对象在这种情况下替换为Factory方法/抽象工厂:从客户端程序传递给Factory类的参数太多,容易出错某些参数可能是可选的,不像工厂中强制发送所有参数

工厂(简单工厂)的显著特点:

创建型模式基于继承Factory返回一个Factory方法(接口),然后返回具体对象您可以用新的具体对象替换接口,客户端(调用者)不应该知道所有具体实现客户端始终只访问接口,您可以在Factory方法中隐藏对象创建详细信息。

通常,设计从使用工厂方法(不那么复杂,更可定制,子类激增)开始,并向抽象工厂、原型或生成器(更灵活,更复杂)发展

查看相关帖子:

将生成器保持在单独的类中(流畅的接口)

设计模式:工厂vs工厂方法vs抽象工厂

有关详细信息,请参阅以下文章:

资源制造

日志记录设备

抽象工厂和生成器模式都是创造性模式,但目的不同。

抽象工厂模式强调为相关对象族创建对象,其中:

每个族都是从公共基类/接口派生的一组类。每个对象都会作为一次调用的结果立即返回。

构建器模式侧重于一步一步地构建一个复杂的对象。它将表示与构造复杂对象的过程解耦,以便相同的构造过程可以用于不同的表示。

Builder对象封装了复杂对象的配置。Director对象知道使用Builder的协议,其中协议定义了构建复杂对象所需的所有逻辑步骤。

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

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

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

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

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