当构造方法参数过多时使用builder模式
静态工厂和构造器有个共同的局限性:它们都不能很好地扩展到大量的可选参数。比如用一个类表示包装食品外面显示的营养成分标签。这些标签中有几个域是必需的:每份的含量、每罐的含量以及每份的卡路里。还有超过20个的可选域:总脂肪量、饱和脂防量、转化脂防、胆固醇、钠，等等。大多数产品在某几个可选域中都会有非零的值。
对于这样的类，应该用哪种构造器或者静态工厂来编写呢?程序员一向习惯采用重叠构造器（telescoping constructor）模式，在这种模式下，提供的第一个构造器只有必要的参数，第二个构造器有一个可选参数，第三个构造器有两个可选参数，依此类推，最后一个构造器包含所有可选的参数。下面有个示例，为了简单起见，它只显示四个可选域：
public class NutritionFacts {private final int servingSize; // (mL) requiredprivate final int servings; // (per container) requiredprivate final int calories; // (per serving) optionalprivate final int fat; // (g/serving) optionalprivate final int sodium; // (mg/serving) optionalprivate final int carbohydrate; // (g/serving) optionalpublic 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 mutabilitypublic class NutritionFacts {// Parameters initialized to default values (if any)private int servingSize = -1; // Required; no default valueprivate int servings = -1; // Required; no default valueprivate int calories = 0;private int fat = 0;private int sodium = 0;private int carbohydrate = 0;public NutritionFacts() { }// Setterspublic 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 Patternpublic 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 parametersprivate final int servingSize;private final int servings;// Optional parameters - initialized to default valuesprivate 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 hierarchiesimport 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; // Defaultpublic 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更加安全。
扫描二维码、获取更多精彩
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
