简介：
静态工厂和构造方法都有一个限制：它们不能很好地扩展到很多可选参数的情景。如果一个对象拥有许多属性，那么通过构造函数和静态工厂方法就不能很好的处理。在Effective Java第三版中说明了这种方案：当构造方法参数过多时使用builder模式
正文：
静态工厂和构造方法都有一个限制：它们不能很好地适应有许多可选参数的情况。考虑一种情况：一个类代表包装食品上的营养成分标签。这些标签有一些必需的属性——每次建议的摄入量，每罐的份量和每份卡路里 ，以及超过20个可选的属性——总脂肪、饱和脂肪、反式脂肪、胆固醇、钠等等。大多数产品都有非零值，只有少数几个可选属性。
应该为这些类编写怎么样的构造函数和静态工厂呢？通常编程人员会使用可伸缩构造函数模式，在这种模式中，只提供了一个只所需参数的构造函数，另一个只有一个可选参数，第三个有两个可选参数，等等，最终在构造函数中包含所有可选参数。这就是它在实践中的样子。为了简便起见，只显示了四个可选属性：
// 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);
通常情况下，这个构造方法的调用会要求你设置许多你不想的设置的参数，但是你被迫为它们传递一个值。在这种情况下，我们会传递一个味0的值为Fat属性。这里“仅仅”有6个参数看起来并不是那么糟糕，但是它会很快变得不可控，随着参数数量的增加。
简单的说，可伸缩构造方法模式是可行的，但是当有很多参数时，很难编写客户端代码，而且很难读懂它。读者不知道这些值是什么意思，并且必须仔细地计算参数才能找到答案。一长串相同类型的参数能造成细微的Bug。如果客户端意外地反转了两个这样的参数，编译器并不会报错，但是程序在运行时会出现错误行为
还有一种替代的方法是使用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可能处于不一致的状态在构造的过程中。该类没有选项去执行保证一致性，通过检查构造参数的有效性。在不一致的状态下尝试使用对象可能会导致与包含bug的代码大相径庭的错误，因此很难调试。一个相关的缺点是，JavaBeans模式排除了让类不可变的可能性，并且需要在程序员的部分增加工作以确保线程安全。
可以减少这些缺点的方式是：通过手动“冻结”对象当构造函数完成时且没有解冻之前不允许使用。但是这种变体在实践中很难使用并且很少使用。 而且，在运行时会导致错误，因为编译器无法确保程序员在使用对象之前调用“冻结”方法。
幸运的是：还有第三种替代方案，它结合了可伸缩构造方法模式的安全性和javabean模式的可读性。它是Builder模式的一种形式。替代直接调用所需的对象，客户端而是调用构造方法(或静态工厂)，使用所有必需的参数，并获得一个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复制参数后对对象属性进行检查。 如果检查失败，则抛出IllegalArgumentException异常，其详细消息指示哪些参数无效。
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是一个带有递归类型参数的泛型类型。 这与抽象self()方法一起，允许方法链在子类中正常工作，而不需要强制转换。 Java缺乏自我类型的这种变通解决方法被称为模拟自我类型（simulated self-type）的习惯用法.
这里有Pizza的两个具体的子类，一个代表了New-York类型的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比JavaBean更安全。
更多文章请关注公众号：每天学Java。想获得更多最新面试提醒请进入小程序：每天学Java
公众号二维码： 小程序二维码：
