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

哪一种更有利?为什么?

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


当前回答

工厂只是一个围绕构造函数(可能是不同类中的一个)的包装函数。关键区别在于,工厂方法模式要求在单个方法调用中构建整个对象,所有参数都在一行中传递。将返回最终对象。

另一方面,构建器模式本质上是一个包装器对象,它围绕着您可能希望传递到构造函数调用中的所有可能参数。这允许您使用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

其他回答

IMHO

Builder是某种更复杂的工厂。

但在Builder中,您可以使用另一个工厂来实例化对象,这是构建最终有效对象所必需的。

所以,谈论“创造性模式”的复杂性演变,你可以这样想:

Dependency Injection Container -> Service Locator -> Builder -> Factory

与工厂模式相比,构建器模式的主要优势在于,如果您希望创建一些具有大量可能自定义的标准对象,但最终通常只能自定义少数对象。

例如,如果你想写一个HTTP客户端,你将设置一些默认参数,比如默认的写/读超时、协议、缓存、DNS、拦截器等。

客户端的大多数用户将只使用这些默认参数,而其他一些用户可能希望自定义一些其他参数。在某些情况下,您只需要更改超时并按原样使用其余部分,而在其他情况下,可能需要自定义例如缓存。

以下是实例化客户端的可能方法(取自OkHttpClient):

//just give me the default stuff
HttpClient.Builder().build()   

//I want to use custom cache
HttpClient.Builder().cache(MyCache()).build() 

//I want custom connection timeout
HttpClient.Builder().connectTimeout(30, TimeUnit.SECONDS).build() 

//I am more interested in read/write timeout
HttpClient.Builder()
        .readTimeout(30, TimeUnit.SECONDS)
        .writeTimeout(30, TimeUnit.SECONDS).build()

如果你使用一个工厂模式,你最终会写出很多方法,包括所有可能的创造参数组合。对于构建器,您只需指定您关心的参数,并让构建器为您构建它,同时考虑所有其他参数。

许多设计从使用工厂方法开始(不太复杂,通过子类更可定制),并向抽象工厂、原型或生成器(更灵活,但更复杂)发展。

Builder专注于逐步构建复杂对象。

实施:

明确定义构建所有可用产品表示的通用构建步骤。否则,您将无法继续实现该模式。在基本生成器接口中声明这些步骤。为每个产品表示创建一个具体的生成器类,并实现它们的构造步骤。

抽象工厂专门创建相关对象的族。Abstract Factory会立即返回产品,而Builder允许您在获取产品之前运行一些额外的构建步骤。

您可以将抽象工厂与Bridge一起使用。当Bridge定义的某些抽象只能用于特定实现时,这种配对非常有用。在这种情况下,抽象工厂可以封装这些关系,并从客户端代码中隐藏复杂性。

深入设计模式

Factory模式几乎可以看作是Builder模式的简化版本。

在Factory模式中,工厂负责根据需要创建对象的各种子类型。

工厂方法的用户不需要知道该对象的确切子类型。工厂方法createCar的示例可能返回Ford或Honda类型的对象。

在生成器模式中,不同的子类型也由生成器方法创建,但同一子类中对象的组成可能不同。

要继续汽车示例,您可能需要一个createCarbuilder方法,该方法创建一个带有4缸发动机的Honda类型的对象,或者一个带有6缸的Honda型对象。构建器模式允许这种更精细的粒度。

生成器模式和工厂方法模式的图表都可以在维基百科上找到。

它们之间的主要区别在于,生成器模式主要描述一步一步创建复杂对象。在抽象工厂模式中,重点是对象系列产品。生成器在最后一步返回产品。在抽象工厂模式中,产品立即可用。

例子:假设我们正在创建迷宫

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();
}