上一篇:用静态工厂方法代替构造器
第 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 个参数,看起来还不算太糟糕,问题是随着参数数目的增加,它很快就失去了控制。
简而言之,重叠构造器模式可行,但是当有许多参数的时候,客户端代码会很难缩写,并且仍然较难以阅读。如果读者想知道那些值是什么意思,必须很仔细地数着这些参数来探个究竟。一长串类型相同的参数会导致一些微妙的错误。如果客户端不小心颠倒了其中两个参数的顺序,编译器也不会出错,但是程序在运行时会出现错误的行为(详见第 51 条)。
遇到许多可选的构造器参数的时候,还有第二种代替办法,即 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 可能处于不一致的状态。 类无法仅仅通过检验构造器参数的有效性来保证一致性。试图使用处于不一致状态的对象将会导致失败,这种失败与包含错误的代码大相径庭,因此调试起来十分困难。与此相关的另一点不足在于,JavaBeans 模式使得把类做成不可变的可能性不复存在(详见第 17 条),这就需要程序员付出额外的努力来确保它 的线程安全。
当对象的构造完成,并且不允许在冻结之前使用时,通过手工“冻结”对象可以弥补这些不足,但是这种方式十分笨拙,在实践中很少使用。此外,它甚至会在运行时导致错误,因为编译器无法确保程序员会在使用之前先调用对象上的 freeze 方法进行冻结。
幸运的是,还有第三种替代方法,它既能保证像重叠构造器模式那样的安全性,也能保证像 JavaBeans 模式那么好的可读性。 这就是建造者(Builder)模式[ Gamma95 ]的一 种形式。 它不直接生成想要的对象,而是让客户端利用所有必要的参数调用构造器(或者静态工厂),得到一个 builder 对象。 然后客户端在 builder 对象上调用类似于 setter 的方法,来设置每个相关的可选参数。最后客户端调用无参的 build 方法来生成通常是不可变的对象。这个 buiider 通常是它构建的类的静态成员类(详见第 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 的设值方法返回 builder 本身,以便把调用链接起来,得到一个流式的 API。 下面就是其客 户端代码 :
NutritionFacts cocaCola = new NutritionFacts.Builder(240, 8)
.calories(100).sodium(35).carbohydrate(27).build();
这样的客户端代码很容易编写,更为重要的是易于阅读。BuiIder 模式模拟了具名的可选参数,就像 Python 和 Scala 编程语言中的一样。
为了简洁起见,示例中省略了有效性检查。 要想尽快侦测到无效的参数, 可以在 builder 的构造器和方法中检查参数的有效性。 查看不可变量,包括 build 方法调用的构造器中的多个参数。为了确保这些不变量免受攻击,从 builder 复制完参数之后,要检查对象域(详见第 50 条) 。 如果检查失败,就抛出 IllegalArgumentException(详见第 72 条),其中的详细信息会说明哪些参数是无效的(详见第 75 条)。
Builder 模式也适用于类层次结构。使用平行层次结构的 builder 时,各自嵌套在相应的类中。抽象类有抽象的 builder,具体类有具体的 builder。假设用类层次根部的一个抽象类表示各式各样的比萨:
// Builder pattern for class hierarchies
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 的类型是泛型(generic type),带有一个递归类型参数(recursive type parameter),详见第 30 条。 它和抽象的 self 方法一样,允许在子类中适当地进行方法链接,不需要转换类型。 这个针对 Java 缺乏 self 类型的解决方案,被称作模拟的 self 类 型(simulated self-type) 。 这里有两个具体的 Pizza 子类,其中一个表示经典纽约风味的比萨,另一个表示馅料内置的半月型( calzone)比萨。 前者需要一个尺寸参数,后者则要你指定酱汁应该内置还是 外置:
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;
}
}
注意,每个子类的构建器中的 build 方法,都声明返回正确的子类:NyPizza.Builder 的 build 方法返回 NyPizza ,而 Cal zone.Builder 中的则返回 Calzone。 在该方法中,子类方法声明返回超级类中声明的返回类型的子类型,这被称作协变返回类型 (covariant return type)。它允许客户端无须转换类型就能使用这些构建器。这些“层次化构建器” 的客户端代码本质上与简单的 NutritionFacts 构建器一样。 为了简洁起见,下列客户端代码示例假设是在枚举常量上静态导入:
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 的参数可以在调用 build 方法来创建对象期间进行调整,也可以随着不同的对象而改变。 builder 可以自动填充某些域,例如每次创建对象时自动增加序列号。
Builder 模式的确也有它自身的不足。 为了创建对象,必须先创建它的构建器。 虽然创建这个构建器的开销在实践中可能不那么明显,但是在某些十分注重性能的情况下,可能就成问题了。 Builder 模式还比重叠构造器模式更加冗长,因此它只在有很多参数的时候才使 用,比如 4 个或者更多个参数。 但是记住,将来你可能需要添加参数。 如果一开始就使用构造器或者静态工厂,等到类需要多个参数时才添加构造器,就会无法控制,那些过时的构造 器或者静态工厂显得十分不协调。 因此,通常最好一开始就使用构建器。
简而言之, 如果类的构造器或者静态工厂中具有多个参数,设计这种类时, Builder 模式就是一种不错的选择, 特别是当大多数参数都是可选或者类型相同的时候。 与使用重叠构造器模式相比,使用 Builder 模式的客户端代码将更易于阅读和编写,构建器也比 JavaBeans 更加安全。