【第2条】遇到多个构造器参数时要考虑使用构建器

当构造方法参数过多时使用builder模式

 

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

对于这样的类，应该用哪种构造器或者静态工厂来编写呢?程序员一向习惯采用重叠构造器（telescoping constructor）模式，在这种模式下，提供的第一个构造器只有必要的参数，第二个构造器有一个可选参数，第三个构造器有两个可选参数，依此类推，最后一个构造器包含所有可选的参数。下面有个示例，为了简单起见，它只显示四个可选域：

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个参数，看起来还不算太槽糕，问题是随着参数数目的增加，它很快就失去了控制。

 

简而言之，重叠构造器模式可行，但是当有许多参数的时候，客户端代码会很难编写，并且仍然较难以阅读。如果读者想知道那些值是什么意思，必须很仔细地数着这些参数来探个究竟。一长串类型相同的参数会导致一些微妙的错误。如果客户端不小心颠倒了其中两个参数的顺序，编译器也不会出错，但是程序在运行时会出现错误的行为(详见第51条)。

 

遇到许多可选的构造器参数的时候，还有第二种代替办法，即 JavaBeans模式，在这种模式下，先调用一个无参构造器来创建对象，然后再调用 setter 方法B来设置每个必要的参数，以及每个相关的可选参数:

// 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 条），并且需要程序员增加工作以确保线程安全。

 

通过在对象构建完成时手动「冻结」对象，并且不允许它在解冻之前使用，可以减少这些缺点，但是这种变体在实践中很难使用并且很少使用。而且，在运行时会导致错误，因为编译器无法确保程序员会在使用对象之前调用 freeze 方法。

 

幸运的是，还有第三种选择。它结合了可伸缩构造方法模式的安全性和 JavaBean 模式的可读性。它是 Builder 模式[Gamma95] 的一种形式。客户端不直接构造所需的对象，而是调用一个包含所有必需参数的构造方法 (或静态工厂) 得到获得一个 builder 对象。然后，客户端调用 builder 对象的与setter 相似的方法来设置你想设置的可选参数。最后，客户端调用 builder 对象的一个无参的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 returntyping）。它允许客户端使用这些 builder，而不需要强制转换。

 

这些「分层 builder（hierarchical builders）」的客户端代码基本上与简单的 NutritionFactsbuilder 的代码相同。为了简洁起见，下面显示的示例客户端代码假设枚举常量的静态导入：

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

与构造器相比、 builder的微略优势在于，它可以有多个可变( varargs)参数。因为 builder是利用单独的方法来设置每一个参数。此外，构造器还可以将多次调用某一个方法而传入的参数集中到一个域中，如前面的调用了两次 addTopping 方法的代码所示。

 

Builder模式十分灵活，可以利用单个 builder构建多个对象。 builder的参数可以在调用buid方法来创建对象期间进行调整，也可以随着不同的对象而改变。 builder可以自动填充某些域，例如每次创建对象时自动增加序列号。

 

Builder模式的确也有它自身的不足。为了创建对象，必须先创建它的构建器。虽然创建这个构建器的开销在实践中可能不那么明显，但是在某些十分注重性能的情况下，可能就成问题了。 Builder模式还比重叠构造器模式更加冗长，因此它只在有很多参数的时候才使用，比如4个或者更多个参数。但是记住，将来你可能需要添加参数。如果一开始就使用构造器或者静态工厂，等到类需要多个参数时才添加构造器，就会无法控制，那些过时的构造器或者静态工厂显得十分不协调。因此，通常最好一开始就使用构建器。

 

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

                                                                                     关注公众号

                                                                                    每天干货分享