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

哪一种更有利?为什么?

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


当前回答

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

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

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

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

其他回答

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

逐步构建复杂对象:构建器模式通过使用单一方法创建一个简单对象:工厂方法模式使用多工厂方法创建对象:抽象工厂模式

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

另一方面,构建器模式本质上是一个包装器对象,它围绕着您可能希望传递到构造函数调用中的所有可能参数。这允许您使用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不是最干净的方式),而另一些依赖项则设置为由某种条件驱动的状态。此外,有些对象财产是某种“不经意的依赖关系”,但它们也可以假定为可选状态。

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

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

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

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

例如,如果你想写一个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()

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