Builder设计模式和Factory设计模式之间的区别是什么?
哪一种更有利?为什么?
如果我想测试和比较/对比这些模式,我如何将我的发现表示为图表?
Builder设计模式和Factory设计模式之间的区别是什么?
哪一种更有利?为什么?
如果我想测试和比较/对比这些模式,我如何将我的发现表示为图表?
当前回答
Builder | Factory |
---|---|
Return only single instance to handle complex object construction | Return various instances on multiple constructors |
No interface required | Interface driven |
Inner classes is involved (to avoid telescopic constructors) | Subclasses are involved |
伸缩构造器模式
类比:
工厂:考虑一家餐馆。创建“今天的饭”是一种工厂模式,因为你告诉厨房“给我今天的饭吃”,厨房(工厂)根据隐藏的标准决定生成什么对象。生成器:如果您订购自定义披萨,则会显示生成器。在这种情况下,服务员告诉厨师(构建者)“我需要一个比萨饼;在其中添加奶酪、洋葱和培根!”因此,构建者公开了生成对象应该具有的属性,但隐藏了如何设置这些属性。
礼貌
其他回答
这两种模式都有相同的必要性:对某些客户端代码隐藏复杂对象的构造逻辑。但是,是什么使一个对象变得“复杂”(或有时变得复杂)?主要是由于依赖关系,或者更确切地说是由更多部分状态组成的对象的状态。您可以通过构造函数注入依赖项来设置初始对象状态,但一个对象可能需要很多依赖项,其中一些依赖项将处于默认初始状态(只是因为我们应该了解到,将默认依赖项设置为null不是最干净的方式),而另一些依赖项则设置为由某种条件驱动的状态。此外,有些对象财产是某种“不经意的依赖关系”,但它们也可以假定为可选状态。
有两种众所周知的方法来控制这种复杂性:
组合/聚合:构造一个对象,构造其依赖对象,然后连接在一起。在这里,构建器可以使确定引导组件构建的规则的过程透明而灵活。多态性:构造规则直接声明到子类型定义中,因此每个子类型都有一组规则,某些条件决定了这些规则中的哪一个适用于构造对象。工厂完全适合这种情况。
没有什么可以阻止这两种方法的混合。一个产品系列可以抽象对象创建,由生成器完成,生成器可以使用工厂来确定实例化哪个组件对象。
构建器设计模式描述了一个对象,该对象知道如何在几个步骤中创建另一个特定类型的对象。它在每个中间步骤保持目标项所需的状态。想想StringBuilder是如何生成最终字符串的。
工厂设计模式描述了一个对象,该对象知道如何在一个步骤中创建几种不同但相关的对象,其中特定类型是基于给定参数选择的。想想串行化系统,在这里创建串行化器,它在一次加载调用中构造所需的in对象。
它们之间的主要区别在于,生成器模式主要描述一步一步创建复杂对象。在抽象工厂模式中,重点是对象系列产品。生成器在最后一步返回产品。在抽象工厂模式中,产品立即可用。
例子:假设我们正在创建迷宫
1.抽象工厂:
Maze* MazeGame::CreateMaze (MazeFactory& factory) {
Maze* maze = factory.MakeMaze(); /// product is available at start!!
/* Call some methods on maze */
return maze;
}
2.建造商:
Maze* MazeGame::CreateMaze (MazeBuilder& builder) {
builder.buildMaze(); /// We don't have access to maze
/* Call some methods on builder */
return builder.GetMaze();
}
工厂模式允许您一次创建一个对象,而生成器模式允许您中断对象的创建过程。这样,您可以在创建对象期间添加不同的功能。
首先,要遵循我的论证:
设计大型软件系统的主要挑战是它们必须灵活且不复杂地进行更改。出于这个原因,有一些度量,如耦合和内聚。为了实现可以轻松更改或扩展其功能而无需从头设计整个系统的系统,您可以遵循设计原则(如SOLID等)。过了一段时间,一些开发人员意识到,如果他们遵循这些原则,就会有一些类似的解决方案可以很好地解决类似问题。这些标准解决方案被证明是设计模式。
因此,设计模式支持您遵循一般设计原则,以实现具有高内聚性的松散耦合系统。
回答问题:
通过询问两种模式之间的差异,你必须问问自己,哪种模式使你的系统更灵活。每个模式都有自己的目的来组织系统中类之间的依赖关系。
抽象工厂模式:GoF:“提供一个接口来创建相关或依赖对象的族,而不指定它们的具体类。”
这意味着什么:通过提供这样的接口,对每个系列产品的构造函数的调用被封装在工厂类中。因为这是整个系统中唯一调用这些构造函数的地方,所以可以通过实现新的工厂类来更改系统。如果您通过另一个交换工厂的表示,则可以在不接触大部分代码的情况下交换一整套产品。
生成器模式:GoF:“将复杂对象的构造与其表示分离,以便相同的构造过程可以创建不同的表示。”
这意味着什么:您将构建过程封装在另一个类中,称为director(GoF)。该导向器包含创建产品新实例的算法(例如,用其他部件组成一个复杂的产品)。为了创建整个产品的组成部分,导演使用了一个生成器。通过在director中交换生成器,您可以使用相同的算法来创建产品,但更改单个零件的表示(以及产品的表示)。要在产品的表示中扩展或修改系统,只需实现一个新的生成器类。
简而言之:抽象工厂模式的目的是交换一组共同使用的产品。生成器模式的目的是封装创建产品的抽象算法,以将其用于产品的不同表示。
在我看来,你不能说抽象工厂模式是生成器模式的大哥。是的,它们都是创造模式,但模式的主要意图完全不同。