第2项：当面临多个参数的构造器时考虑使用构建器

摘要：因此，最好一开始就考虑使用构造器。与使用传统的重叠构造器模式相比，使用模式的客户端代码更易于阅读和编写，构建器也比更加安全。

  静态工厂和构造器有个共同的局限性：他们都不能很好地扩展到大量的可选参数。考虑用一个类表示包装食品外面显示的营养成分标签。这些标签中有几个域是必需的：每份的含量、每罐的含量以及每份的卡路里，还有超过20个可选域：总脂肪、饱和脂肪量、转化脂肪、胆固醇、钠等等。大多数产品在某几个可选域中都会有非零的值。

  对于这样的类，应该采用哪种构造器或者静态方法来编写呢？程序猿一向习惯采用重叠构造器(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;
    }
}

  当你想要创建实例的时候，就利用参数列表最短的构造器，但该列表中包含了要设置的所有参数：NutritionFacts cocaCola = new NutritionFacts(240, 8, 100, 0, 35, 27);这个构造器调用通常需要许多你本不想设置的参数，但还是不得不为它们传递值。在这个例子中，我们给fat传递了一个值为0。如果“仅仅”是这6个参数，看起来还不算太糟，问题是随着参数数目的增加，它很快就失去了控制。

  总的来说，使用重叠构造器模式是可行的，但是当有很多参数的时候就很难编写客户端代码，也很难去阅读它们。如果读者想要知道这些值代表什么意思，就必须仔细地数着这些参数来探个究竟。一长串类型相同的参数会导致一些微妙的错误，如果客户端不小心颠倒了期中两个参数的顺序，编译器也不会报错，但是程序在运行的时候就会出现错误的行为。

  遇到许多构造器参数的时候，还有第二种代替方法，即JavaBean模式，在这种模式下，调用一个无参构造器来创建对象，然后调用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);

  遗憾的是，这种JavaBean模式自身有很严重的缺点。因为构造过程被分到了几个调用中，在构造的过程中JavaBean可能处于不一致的状态。类无法通过检验构造器参数的有效性来保证一致性。试图使用处于不一致状态的对象，将会导致失败，这种失败与包含错误的代码大相径庭，因此它调试起来十分困难。与此相关的另一点不足在于，JavaBean模式阻止了把类做成了不可变的可能(第17项)，这就需要程序猿付出额外的努力来保证它的线程安全。

  在构造器完成构造对象之前进行加锁，完成构造之后进行解锁，这就能弥补以上的不足之处，但是这种方式十分笨拙，在实践中很少使用。此外，它甚至会在运行时出现错误，因为编译器无法确保程序猿会在使用构造器之前进行加锁操作。

  幸运的是，还有第三种替代方法，结合了重叠构造器的安全性和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本身，以便可以把调用连接起来。下面是客户端代码：

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

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

  为简洁起见，省略了有效性检查。 要尽快检测无效参数，请在构建器的构造函数和方法中检查参数有效性。 检查构建方法调用的构造函数中涉及多个参数的不变量。 要确保这些不变量不受攻击，请在从构建器复制参数后对对象字段执行检查(第50项)。 如果检查失败，则抛出IllegalArgumentException(第72项)，其详细消息指示哪些参数无效(第75项)。

  Builder模式非常适合类层次结构。 使用并行的构建器层次结构，每个构建器都嵌套在相应的类中。 抽象类有抽象构建器; 具体课程有混凝土建造者。例如，在代表各种批萨的层次结构的根部考虑使用一个抽象类：

// Builder pattern for class hierarchies
public abstract class Pizza {
    public enum Topping { HAM, MUSHROOM, ONION, PEPPER, SAUSAGE }
    final Set toppings;
    abstract static class Builder> {
        EnumSet 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是具有递归类型参数的通用类型(第30项)。 这与抽象方法self一起允许方法链在子类中正常工作，而不需要强制转换。Java缺乏自我类型这一事实的解决方法被称为模拟自我类型习语(This workaround for the fact that Java lacks a self type is known as the simulated self-type idiom.)。

  这是Pizza的两个具体子类，其中一个代表标准的纽约式披萨，另一个代表calzone。 前者具有所需的大小参数，而后者允许你指定酱汁应该在内部还是外部：

public class NyPizza extends Pizza {
    public enum Size { SMALL, MEDIUM, LARGE }
    private final Size size;
    public static class Builder extends Pizza.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 {
        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;
    }
}

  请注意，每个子类的构建器中的构建方法被声明为返回正确的子类：NyPizza.Builder的构建方法返回NyPizza，而Calzone.Builder中的构建方法返回Calzone。这种技术，其中子类方法声明的返回类型是在超类中声明的返回类型的子类型，称为协变返回类型，它允许客户使用这些构建器而无需进行创建。

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

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

  构建器相对于构造函数的一个小优点是构建器可以有多个可变参数，因为每个参数都是在自己的方法中指定的。除此之外，构建器可以将传递给一个方法的多个参数通过多次调用方法的方式聚合到一个字段中，就如之前addTopping方法中所演示的那样。

  Builder模式非常灵活。 可以重复使用单个构建器来构建多个对象。 可以在构建方法的调用之间调整构建器的参数，以改变创建的对象。构建器可以在创建对象时自动填充某些字段，例如每次创建对象时增加的序列号。

  Builder模式也有缺点。 要创建对象，必须先创建其构建器。 虽然在实践中创建此构建器的成本不太可能明显，但在性能关键的情况下可能会出现问题。此外，Builder模式比重叠构造函数的模式更冗长，因此只有在有足够的参数(例如四个或更多)时才值得去使用它。 但请记住，你可能希望在将来添加更多的参数。但是如果你从构造函数或静态工厂开始并在类进化到参数数量失控时才切换到构建器，那些过时的构造器和静态工厂就会显得非常不协调。因此，最好一开始就考虑使用构造器。

  简而言之，如果类的构造器或者静态工厂方法中具有多个参数，设计这种类时，Builder模式就是种不错的选择，特别是当大多数参数都是可选的时候。与使用传统的重叠构造器模式相比，使用Builder模式的客户端代码更易于阅读和编写，构建器也比JavaBean更加安全。