Effective Java 第三版——2. 当构造方法参数过多时使用builder模式

时间  2019-11-06
标签 effective java 第三 构造 方法 参数 过多 使用 builder 模式 栏目 Java 繁體版
原文   原文链接

Tips
书中的源代码地址：https://github.com/jbloch/effective-java-3e-source-code
注意，书中的有些代码里方法是基于Java 9 API中的，因此JDK 最好下载 JDK 9以上的版本。java

Effective Java, Third Edition

条目2：当构造方法参数过多时使用builder模式

静态工厂和构造方法都有一个限制：它们不能很好地扩展到不少可选参数的情景。请考虑一个表明包装食品上的养分成分标签的例子。这些标签有几个必需的属性——每次建议的摄入量，每罐的分量和每份卡路里 ，以及超过20个可选的属性——总脂肪、饱和脂肪、反式脂肪、胆固醇、钠等等。大多数产品都有非零值，只有少数几个可选属性。git

应该为这样的类编写什么样的构造方法或静态工厂？传统上，程序员使用了可伸缩（telescoping constructor）构造方法模式，在这种模式中，只提供了一个只所需参数的构造函数，另外一个只有一个可选参数，第三个有两个可选参数，等等，最终在构造函数中包含全部可选参数。这就是它在实践中的样子。为了简便起见，只显示了四个可选属性：程序员

// Telescoping constructor pattern - does not scale well!

public class NutritionFacts {
    private final int servingSize;  // (mL)            required
    private final int servings;     // (per container) required
    private final int calories;     // (per serving)   optional
    private final int fat;          // (g/serving)     optional
    private final int sodium;       // (mg/serving)    optional
    private final int carbohydrate; // (g/serving)     optional

    public NutritionFacts(int servingSize, int servings) {
        this(servingSize, servings, 0);
    }

    public NutritionFacts(int servingSize, int servings,
            int calories) {
        this(servingSize, servings, calories, 0);
    }

    public NutritionFacts(int servingSize, int servings,
            int calories, int fat) {
        this(servingSize, servings, calories, fat, 0);
    }

    public NutritionFacts(int servingSize, int servings,
            int calories, int fat, int sodium) {
        this(servingSize, servings, calories, fat, sodium, 0);
    }

    public NutritionFacts(int servingSize, int servings,
           int calories, int fat, int sodium, int carbohydrate) {
        this.servingSize  = servingSize;
        this.servings     = servings;
        this.calories     = calories;
        this.fat          = fat;
        this.sodium       = sodium;
        this.carbohydrate = carbohydrate;
    }
}

当想要建立一个实例时，可使用包含全部要设置的参数的最短参数列表的构造方法：github

NutritionFacts cocaCola = new NutritionFacts(240, 8, 100, 0, 35, 27);

一般状况下，这个构造方法的调用须要许多你不想设置的参数，可是你不得不为它们传递一个值。 在这种状况下，咱们为fat属性传递了0值。 『只有』六个参数可能看起来并不那么糟糕，但随着参数数量的增长，它会很快失控。安全

简而言之，可伸缩构造方法模式是有效的，可是当有不少参数时，很难编写客户端代码，并且很难读懂它。读者不知道这些值是什么意思，而且必须仔细地计算参数才能找到答案。一长串相同类型的参数可能会致使一些细微的bug。若是客户端意外地颠倒了两个这样的参数，编译器并不会抱怨，可是程序在运行时会出现错误行为(条目51)。ide

当在构造方法中遇到许多可选参数时，另外一种选择是JavaBeans模式，在这种模式中，调用一个无参数的构造函数来建立对象，而后调用setter方法来设置每一个必需的参数和可选参数：函数

// JavaBeans Pattern - allows inconsistency, mandates mutability

public class NutritionFacts {
    // Parameters initialized to default values (if any)
    private int servingSize  = -1; // Required; no default value
    private int servings     = -1; // Required; no default value
    private int calories     = 0;
    private int fat          = 0;
    private int sodium       = 0;
    private int carbohydrate = 0;

    public NutritionFacts() { }

    // Setters
    public void setServingSize(int val)  { servingSize = val; }
    public void setServings(int val)    { servings = val; }
    public void setCalories(int val)    { calories = val; }
    public void setFat(int val)         { fat = val; }
    public void setSodium(int val)      { sodium = val; }
    public void setCarbohydrate(int val) { carbohydrate = val; }
}

这种模式没有伸缩构造方法模式的缺点。有点冗长，但建立实例很容易，而且易于阅读所生成的代码:性能

NutritionFacts cocaCola = new NutritionFacts();
cocaCola.setServingSize(240);
cocaCola.setServings(8);
cocaCola.setCalories(100);
cocaCola.setSodium(35);
cocaCola.setCarbohydrate(27);

不幸的是，JavaBeans模式自己有严重的缺陷。因为构造方法在屡次调用中被分割，因此在构造过程当中JavaBean可能处于不一致的状态。该类没有经过检查构造参数参数的有效性来执行一致性的选项。在不一致的状态下尝试使用对象可能会致使与包含bug的代码截然不同的错误，所以很难调试。一个相关的缺点是，JavaBeans模式排除了让类不可变的可能性(条目17)，而且须要在程序员的部分增长工做以确保线程安全。ui

当它的构造完成时，手动“冻结”对象，而且不容许它在解冻以前使用，能够减小这些缺点，可是这种变体在实践中很难使用而且不多使用。 并且，在运行时会致使错误，由于编译器没法确保程序员在使用对象以前调用freeze方法。this

幸运的是，还有第三种选择，它结合了可伸缩构造方法模式的安全性和javabean模式的可读性。 它是Builder模式[Gamma95]的一种形式。客户端不直接调用所需的对象，而是调用构造方法(或静态工厂)，并使用全部必需的参数，并得到一个builder对象。而后，客户端调用builder对象的setter类似方法来设置每一个可选参数。最后，客户端调用一个无参的build方法来生成对象，该对象一般是不可变的。Builder一般是它所构建的类的一个静态成员类(条目24)。如下是它在实践中的示例：

// Builder Pattern

public class NutritionFacts {
    private final int servingSize;
    private final int servings;
    private final int calories;
    private final int fat;
    private final int sodium;
    private final int carbohydrate;

    public static class Builder {
        // Required parameters
        private final int servingSize;
        private final int servings;

        // Optional parameters - initialized to default values
        private int calories      = 0;
        private int fat           = 0;
        private int sodium        = 0;
        private int carbohydrate  = 0;

        public Builder(int servingSize, int servings) {
            this.servingSize = servingSize;
            this.servings    = servings;
        }

        public Builder calories(int val) { 
            calories = val;      
            return this;
        }

        public Builder fat(int val) { 
           fat = val;           
           return this;
        }

        public Builder sodium(int val) { 
           sodium = val;        
           return this; 
        }

        public Builder carbohydrate(int val) { 
           carbohydrate = val;  
           return this; 
        }

        public NutritionFacts build() {
            return new NutritionFacts(this);
        }
    }

    private NutritionFacts(Builder builder) {
        servingSize  = builder.servingSize;
        servings     = builder.servings;
        calories     = builder.calories;
        fat          = builder.fat;
        sodium       = builder.sodium;
        carbohydrate = builder.carbohydrate;
    }
}

NutritionFacts类是不可变的，全部的参数默认值都在一个地方。builder的setter方法返回builder自己，这样调用就能够被连接起来，从而生成一个流畅的API。下面是客户端代码的示例：

NutritionFacts cocaCola = new NutritionFacts.Builder(240, 8)
    .calories(100).sodium(35).carbohydrate(27).build();

这个客户端代码很容易编写，更重要的是易于阅读。 Builder模式模拟Python和Scala中的命名可选参数。

为了简洁起见，省略了有效性检查。 要尽快检测无效参数，检查builder的构造方法和方法中的参数有效性。 在build方法调用的构造方法中检查包含多个参数的不变性。为了确保这些不变性不受攻击，在从builder复制参数后对对象属性进行检查（条目 50）。 若是检查失败，则抛出IllegalArgumentException异常（条目 72），其详细消息指示哪些参数无效（条目 75）。

Builder模式很是适合类层次结构。 使用平行层次的builder，每一个嵌套在相应的类中。 抽象类有抽象的builder; 具体的类有具体的builder。 例如，考虑表明各类比萨饼的根层次结构的抽象类：

// Builder pattern for class hierarchies

import java.util.EnumSet;
import java.util.Objects;
import java.util.Set;

public abstract class Pizza {
    public enum Topping {HAM, MUSHROOM, ONION, PEPPER, SAUSAGE}
    final Set<Topping> toppings;
    
    abstract static class Builder<T extends Builder<T>> {
        EnumSet<Topping> toppings = EnumSet.noneOf(Topping.class);

        public T addTopping(Topping topping) {
            toppings.add(Objects.requireNonNull(topping));
            return self();
        }
        
        abstract Pizza build();
        
        // Subclasses must override this method to return "this"
        protected abstract T self();
    }

    Pizza(Builder<?> builder) {
        toppings = builder.toppings.clone(); // See Item 50
    }
}

请注意，Pizza.Builder是一个带有递归类型参数（ recursive type parameter）（条目 30）的泛型类型。 这与抽象的self方法一块儿，容许方法链在子类中正常工做，而不须要强制转换。 Java缺少自我类型的这种变通解决方法被称为模拟自我类型（simulated self-type）的习惯用法。

这里有两个具体的Pizza的子类，其中一个表明标准的纽约风格的披萨，另外一个是半圆形烤乳酪馅饼。前者有一个所需的尺寸参数，然后者则容许指定酱汁是否应该在里面或在外面：

import java.util.Objects;

public class NyPizza extends Pizza {
    public enum Size { SMALL, MEDIUM, LARGE }
    private final Size size;

    public static class Builder extends Pizza.Builder<Builder> {
        private final Size size;

        public Builder(Size size) {
            this.size = Objects.requireNonNull(size);
        }

        @Override public NyPizza build() {
            return new NyPizza(this);
        }

        @Override protected Builder self() {
            return this;
        }
    }

    private NyPizza(Builder builder) {
        super(builder);
        size = builder.size;
    }
}

public class Calzone extends Pizza {
    private final boolean sauceInside;
    
    public static class Builder extends Pizza.Builder<Builder> {
        private boolean sauceInside = false; // Default

        public Builder sauceInside() {
            sauceInside = true;
            return this;
        }
        
        @Override public Calzone build() {
            return new Calzone(this);
        }
        
        @Override protected Builder self() {
            return this; 
        }
    }
    
    private Calzone(Builder builder) {
        super(builder);
        sauceInside = builder.sauceInside;
    }
}

请注意，每一个子类builder中的build方法被声明为返回正确的子类：NyPizza.Builder的build方法返回NyPizza，而Calzone.Builder中的build方法返回Calzone。 这种技术，其一个子类的方法被声明为返回在超类中声明的返回类型的子类型，称为协变返回类型( covariant return typing)。 它容许客户端使用这些builder，而不须要强制转换。

这些“分层builder”的客户端代码基本上与简单的NutritionFacts builder的代码相同。为了简洁起见,下面显示的示例客户端代码假设枚举常量的静态导入：

NyPizza pizza = new NyPizza.Builder(SMALL)
        .addTopping(SAUSAGE).addTopping(ONION).build();
Calzone calzone = new Calzone.Builder()
        .addTopping(HAM).sauceInside().build();

builder对构造方法的一个微小的优点是，builder能够有多个可变参数，由于每一个参数都是在它本身的方法中指定的。或者，builder能够将传递给多个调用的参数聚合到单个属性中，如前面的addTopping方法所演示的那样。

Builder模式很是灵活。 单个builder能够重复使用来构建多个对象。 builder的参数能够在构建方法的调用之间进行调整，以改变建立的对象。 builder能够在建立对象时自动填充一些属性，例如每次建立对象时增长的序列号。

Builder模式也有缺点。为了建立对象，首先必须建立它的builder。虽然建立这个builder的成本在实践中不太可能被注意到，但在性能关键的状况下可能会出现问题。并且，builder模式比伸缩构造方法模式更冗长，所以只有在有足够的参数时才值得使用它，好比四个或更多。可是请记住，若是但愿在未来添加更多的参数。可是，若是从构造方法或静态工厂开始，并切换到builder，当类演化到参数数量失控的时候，过期的构造方法或静态工厂就会面临尴尬的处境。所以，因此，最好从一开始就建立一个builder。

总而言之，当设计类的构造方法或静态工厂的参数超过几个时，Builder模式是一个不错的选择，特别是若是许多参数是可选的或相同类型的。客户端代码比使用伸缩构造方法（telescoping constructors）更容易读写，而且builder比JavaBeans更安全。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程