Builder设计模式和Factory设计模式之间的区别是什么?
哪一种更有利?为什么?
如果我想测试和比较/对比这些模式,我如何将我的发现表示为图表?
Builder设计模式和Factory设计模式之间的区别是什么?
哪一种更有利?为什么?
如果我想测试和比较/对比这些模式,我如何将我的发现表示为图表?
当前回答
它们之间的主要区别在于,生成器模式主要描述一步一步创建复杂对象。在抽象工厂模式中,重点是对象系列产品。生成器在最后一步返回产品。在抽象工厂模式中,产品立即可用。
例子:假设我们正在创建迷宫
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();
}
其他回答
逐步构建复杂对象:构建器模式通过使用单一方法创建一个简单对象:工厂方法模式使用多工厂方法创建对象:抽象工厂模式
工厂只是一个围绕构造函数(可能是不同类中的一个)的包装函数。关键区别在于,工厂方法模式要求在单个方法调用中构建整个对象,所有参数都在一行中传递。将返回最终对象。
另一方面,构建器模式本质上是一个包装器对象,它围绕着您可能希望传递到构造函数调用中的所有可能参数。这允许您使用setter方法来缓慢地建立参数列表。生成器类上的另一个方法是build()方法,它简单地将生成器对象传递到所需的构造函数中,并返回结果。
在像Java这样的静态语言中,当您有多个(可能是可选的)参数时,这就变得更加重要,因为它避免了对所有可能的参数组合使用伸缩构造函数的要求。此外,生成器允许您使用setter方法来定义在调用构造函数后不能直接修改的只读或私有字段。
基本工厂示例
// Factory
static class FruitFactory {
static Fruit create(name, color, firmness) {
// Additional logic
return new Fruit(name, color, firmness);
}
}
// Usage
Fruit fruit = FruitFactory.create("apple", "red", "crunchy");
基本生成器示例
// Builder
class FruitBuilder {
String name, color, firmness;
FruitBuilder setName(name) { this.name = name; return this; }
FruitBuilder setColor(color) { this.color = color; return this; }
FruitBuilder setFirmness(firmness) { this.firmness = firmness; return this; }
Fruit build() {
return new Fruit(this); // Pass in the builder
}
}
// Usage
Fruit fruit = new FruitBuilder()
.setName("apple")
.setColor("red")
.setFirmness("crunchy")
.build();
比较这两个维基百科页面的代码样本可能是值得的:
http://en.wikipedia.org/wiki/Factory_method_patternhttp://en.wikipedia.org/wiki/Builder_pattern
这两种模式都有相同的必要性:对某些客户端代码隐藏复杂对象的构造逻辑。但是,是什么使一个对象变得“复杂”(或有时变得复杂)?主要是由于依赖关系,或者更确切地说是由更多部分状态组成的对象的状态。您可以通过构造函数注入依赖项来设置初始对象状态,但一个对象可能需要很多依赖项,其中一些依赖项将处于默认初始状态(只是因为我们应该了解到,将默认依赖项设置为null不是最干净的方式),而另一些依赖项则设置为由某种条件驱动的状态。此外,有些对象财产是某种“不经意的依赖关系”,但它们也可以假定为可选状态。
有两种众所周知的方法来控制这种复杂性:
组合/聚合:构造一个对象,构造其依赖对象,然后连接在一起。在这里,构建器可以使确定引导组件构建的规则的过程透明而灵活。多态性:构造规则直接声明到子类型定义中,因此每个子类型都有一组规则,某些条件决定了这些规则中的哪一个适用于构造对象。工厂完全适合这种情况。
没有什么可以阻止这两种方法的混合。一个产品系列可以抽象对象创建,由生成器完成,生成器可以使用工厂来确定实例化哪个组件对象。
构建模式强调创建对象的复杂性(通过“步骤”解决)
抽象模式强调(多个但相关的)对象的“抽象”。
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 |
伸缩构造器模式
类比:
工厂:考虑一家餐馆。创建“今天的饭”是一种工厂模式,因为你告诉厨房“给我今天的饭吃”,厨房(工厂)根据隐藏的标准决定生成什么对象。生成器:如果您订购自定义披萨,则会显示生成器。在这种情况下,服务员告诉厨师(构建者)“我需要一个比萨饼;在其中添加奶酪、洋葱和培根!”因此,构建者公开了生成对象应该具有的属性,但隐藏了如何设置这些属性。
礼貌