Character 2 Creating and Destroying objects
构造方法参数较多时考虑builder模式
问题场景
静态工厂和构造器共有一个限制：在可选参数很多的情况下，这两个都不能够很好的scale。
考虑一个代表在袋装食物上的营养标签的类，这些标签有一些必须要求的field，建议摄入量，每罐的量以及每份的卡路里，还有超过20个可选的field，总脂肪、饱和脂肪、反式脂肪、胆固醇、钠等等。大多数产品只包含这些可选字段中的少数，且具有非零值(大部分为null)
对于上面所述的class，你会采用什么样的构造器或者静态工厂方法呢？
方法一：telescoping constructor
传统上，程序员使用 telescope constructor (可伸缩模式)，也就是提供一个只有必须参数的构造方法函数，然后提供只有一个可选参数的构造函数，只有两个可选参数的构造函数并以此类推一直到包含所有可选参数的构造函数。实际上如下所示，为了简单，这里只显示四个可选属性：
// telscoping constructor pattern -- no scale well
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 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 NutritionFacrs(int servingSize, int servings, int calories, int fat, int sodium) {
this(servingSize, servings, calories, fat, sodium, 0);
}
public NutritionsFacts(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。只有六个参数看起来不那么糟糕，但是随着参数的增加就会失控。
简而言之，这种telescopeing constructor 模式是有效的，但是当有很多参数的时候，是很难写出客户端代码并且很难读。阅读者看到这样的代码之后，只剩下迷惑这些的意义只能通过数参数的个数明白意思。一长串相同类型的参数可能会导致一些bug，如果客户端不小心写反了两个参数，编译器不会报错，但是程序会出现非预期的行为(见51条)
方法二：JavaBeans
当面对构造方法中有很多可选参数时，第二种方法可以考虑JavaBeans模式，在这种模式中，调用没有参数的构造方法去创建一个对象，然后调用setter方法来设置每个必须参数和可选参数：
//JavaBeans pattern - allow inconsistency, mandates mutability
public class NutritionFacts {
// parameters initialized to default values(if any)
private int servingSize = -1;
private int servings = -1;
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;}
}
这种模式不存在上述telescoping constructor模式的缺点。有点冗长，但是创建实例很简单，并且易于阅读代码。
NutritionFacts cocaCola = new NutritionFacts();
cocaCola.setServingSize(240);
cocaCola.setServings(8);
cocaCola.setCalories(100);
cocaCola.setSodium(35);
cocaCola.setCarbohydrate(27);
不幸的是，JavaBeans模式本身有很严重的缺点，由于构造方法被分割成了多次调用，所以在构造过程中，JavaBeans可能处于不一致状态。这个类通过检查构造函数参数的有效性并不能加强一致性。在不一致的状态下调用对象可能导致失败，这些错误和平常代码的bug很不同，很难调试。相关的另一个缺点就是JavaBeans模式排除了让类不可变的可能性(可见17)，并且为了确保线程安全需要增加工作。
通过在对象构建完成时freezing对象，并且不允许解冻之前使用，可以减少上述缺点，但是这种方法在实际中很难使用。同时，更容易引起错误，因为编译器无法确保程序员会在使用对象之前调用freeze方法。
方法三：builder
幸运的是这里还有第三种方法，结合了telescopeing constructor的安全性以及JavaBeans的可读性。那就是builder (Gramma95)模式。客户端不直接构造对象，而是调用一个包含所有必须参数构造方法(或静态工厂)获得一个builder对象。然后客户端调用builder对象的与setter相似的方法去设置可选参数。最后，客户端调用无参数的build方法去产生一个不可改变的对象。builder是典型的静态成员类(item24).下面是示例：
// 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 NutritiionFacts.Builder(240,8).calories(100).sodium(35).carbohydrate(27).build();
上述客户端的代码很容易编写，更重要的是易于阅读。采用Builder模式模拟的可选参数在python和scala中发现。
为了简洁，有效性检查被省略。为了尽快检测出无效参数，在builder的构造方法和函数中检查参数有效性，包括多个参数的不变性。为了确保这些不变性不受到攻击，在从builder中copy参数后对对象属性进行check(item 50).如果检查失败，就报出IllegalArgumentException(item 72)，详细信息表明那些参数无效(item 75)。
Builder模式非常适合层次结构。使用平行层次的builder, 每个builder嵌套在相应的类。抽象类有抽象的builder，具体类有具体的builder。例如考虑一个代表各种披萨的根层次结构的抽象类：
// builder pattern for class hierarchies -- more
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()
//subclass must override this method return "this"
protected abstract T self();
}
Pizza(Builder<?> builder) {
toppings = builder.toppings.clone(); // see item 50
}
}
注意到Pizza.Builder是一个递归参数(item 30)的泛型类型。这和抽象的self方法一起，允许方法链在子类中可以work，不需要强制类型转换。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 return typing）。 它允许客户端使用这些 builder，而不需要强制转换。
这些分层 builder（hierarchical builders）的客户端代码基本上与简单的 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 模式是一个不错的选择，特别是许多参数是可选的或相同类型的。builder 模式客户端代码比使用伸缩构造方法（telescoping constructors）更容易读写，并且 builder 模式比 JavaBeans 更安全。
扫一扫
1756
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
