Builder设计模式和Factory设计模式之间的区别是什么?
哪一种更有利?为什么?
如果我想测试和比较/对比这些模式,我如何将我的发现表示为图表?
Builder设计模式和Factory设计模式之间的区别是什么?
哪一种更有利?为什么?
如果我想测试和比较/对比这些模式,我如何将我的发现表示为图表?
当前回答
逐步构建复杂对象:构建器模式通过使用单一方法创建一个简单对象:工厂方法模式使用多工厂方法创建对象:抽象工厂模式
其他回答
这两种模式都有相同的必要性:对某些客户端代码隐藏复杂对象的构造逻辑。但是,是什么使一个对象变得“复杂”(或有时变得复杂)?主要是由于依赖关系,或者更确切地说是由更多部分状态组成的对象的状态。您可以通过构造函数注入依赖项来设置初始对象状态,但一个对象可能需要很多依赖项,其中一些依赖项将处于默认初始状态(只是因为我们应该了解到,将默认依赖项设置为null不是最干净的方式),而另一些依赖项则设置为由某种条件驱动的状态。此外,有些对象财产是某种“不经意的依赖关系”,但它们也可以假定为可选状态。
有两种众所周知的方法来控制这种复杂性:
组合/聚合:构造一个对象,构造其依赖对象,然后连接在一起。在这里,构建器可以使确定引导组件构建的规则的过程透明而灵活。多态性:构造规则直接声明到子类型定义中,因此每个子类型都有一组规则,某些条件决定了这些规则中的哪一个适用于构造对象。工厂完全适合这种情况。
没有什么可以阻止这两种方法的混合。一个产品系列可以抽象对象创建,由生成器完成,生成器可以使用工厂来确定实例化哪个组件对象。
抽象工厂和生成器模式都是创造性模式,但目的不同。
抽象工厂模式强调为相关对象族创建对象,其中:
每个族都是从公共基类/接口派生的一组类。每个对象都会作为一次调用的结果立即返回。
构建器模式侧重于一步一步地构建一个复杂的对象。它将表示与构造复杂对象的过程解耦,以便相同的构造过程可以用于不同的表示。
Builder对象封装了复杂对象的配置。Director对象知道使用Builder的协议,其中协议定义了构建复杂对象所需的所有逻辑步骤。
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 |
伸缩构造器模式
类比:
工厂:考虑一家餐馆。创建“今天的饭”是一种工厂模式,因为你告诉厨房“给我今天的饭吃”,厨房(工厂)根据隐藏的标准决定生成什么对象。生成器:如果您订购自定义披萨,则会显示生成器。在这种情况下,服务员告诉厨师(构建者)“我需要一个比萨饼;在其中添加奶酪、洋葱和培根!”因此,构建者公开了生成对象应该具有的属性,但隐藏了如何设置这些属性。
礼貌
生成器模式和工厂模式看起来都很像肉眼,因为它们都为您创建对象。
但你需要仔细观察
这个现实生活中的例子将使两者之间的区别更加明显。
假设你去了一家快餐店,点了食物。
1) 什么食物?
披萨
2) 什么浇头?
辣椒,番茄,烤鸡,无菠萝
因此,不同种类的食物是通过工厂模式制作的,但特定食物的不同变体(口味)是通过构建模式制作的。
不同种类的食物
披萨、汉堡、意大利面
披萨的变体
只有奶酪、奶酪+番茄+辣椒、奶酪+西红柿等。
代码示例
您可以在这里看到这两种模式的示例代码实现生成器模式工厂模式
Factory模式几乎可以看作是Builder模式的简化版本。
在Factory模式中,工厂负责根据需要创建对象的各种子类型。
工厂方法的用户不需要知道该对象的确切子类型。工厂方法createCar的示例可能返回Ford或Honda类型的对象。
在生成器模式中,不同的子类型也由生成器方法创建,但同一子类中对象的组成可能不同。
要继续汽车示例,您可能需要一个createCarbuilder方法,该方法创建一个带有4缸发动机的Honda类型的对象,或者一个带有6缸的Honda型对象。构建器模式允许这种更精细的粒度。
生成器模式和工厂方法模式的图表都可以在维基百科上找到。