第二条：遇到多个构造器参数时要考虑用构建器
静态工厂和构造器有个共同的局限性；它们都不能很好地扩展到大量的可选参数。考虑用一个类表示包装食品外面显示的营养成分标签。这些标签中有几个域是必须的；每份的含量、每罐的含量以及每份的卡路里，还有超过20个可选域：总脂肪量、饱和脂肪量、转化脂肪、胆固醇、钠等等。大多数产品在某几个可选域都会有非零的值
对于这样的类，一般情况下会习惯采用重叠构造器（telescoping constructor）模式，在这种模式下，提供第一个只有有必要参数的构造器，第二个构造器有一个可选参数，第三个有两个可选参数，依次类推，最后一个构造器包含所有可选参数。下面有个示例，为了简单起见，它只显示四个可选域：
/**
* @author: Hashub小晖
* @WeChat: NGSHMVP
* @Date: ${DATA} 20:20
* @function:
*/
public class NutritionFacts
{
public final int servingSize;//(ml)require
public final int servings;//(per container)require
public final int calories;//optional
public final int fat;//(g)optional
public final int sodium;//(mg)optional
public final int carbohydrate;//(g)optional
public NutritionFacts(int servingSize, int servings)
{
this(servingSize,servings,0);//调用第二个构造器
}
public NutritionFacts(int servingSize, int servings, int calories)
{
this(servingSize,servings,calories,0);//调用第3个构造器
}
public NutritionFacts(int servingSize, int servings, int calories, int fat)
{
this(servingSize,servings,calories,fat,0);//调用第4个构造器
}
public NutritionFacts(int servingSize, int servings, int calories, int fat, int sodium)
{
this(servingSize,servings,calories,fat,sodium,0);//调用第5个构造器
}
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 nutritionFacts = new NutritionFacts(240, 8,0,0,0,0);
如果仅仅只是6个参数，看起来还不算太糟糕，问题是随着参数数目的增加，它很快会失去控制。
重叠构造器可行，但是当有许多参数的时候，客户端代码会很难编写，并且仍然难以阅读，必须很仔细地数着这些参数来探个究竟。
JavaBeans模式
遇到许多构造器参数的时候，JavaBeans模式也是一种选择，调用一个无参构造器来创建对象，然后调用setter方法来设置每个必要的参数，以及每个相关的可选参数。
/**
* @author: Hashub小晖
* @WeChat: NGSHMVP
* @Date: 2018/9/30 21:22
* @function:JavaBeans 模式
* JavaBeans Pattern - allows inconsistency , mandates mutability
*/
public class NutritionFacts2
{
public int servingSize=-1;//(ml)require
public int servings=0;//(per container)require
public int calories=0;//optional
public int fat=0;//(g)optional
public int sodium=0;//(mg)optional
public int carbohydrate=0;//(g)optional
/**
* 空参构造器
*/
public NutritionFacts2()
{
}
//setter&getter
public int getServingSize()
{
return servingSize;
}
public void setServingSize(int servingSize)
{
this.servingSize = servingSize;
}
public int getServings()
{
return servings;
}
public void setServings(int servings)
{
this.servings = servings;
}
public int getCalories()
{
return calories;
}
public void setCalories(int calories)
{
this.calories = calories;
}
public int getFat()
{
return fat;
}
public void setFat(int fat)
{
this.fat = fat;
}
public int getSodium()
{
return sodium;
}
public void setSodium(int sodium)
{
this.sodium = sodium;
}
public int getCarbohydrate()
{
return carbohydrate;
}
public void setCarbohydrate(int carbohydrate)
{
this.carbohydrate = carbohydrate;
}
}
这种模式弥补了重叠构造器模式的不足。创建实例很容易，产生的代码读起来也很容易
NutritionFacts2 nutritionFacts2 = new NutritionFacts2();
nutritionFacts2.setServingSize(240);
nutritionFacts2.setServings(240);
nutritionFacts2.setFat(240);
nutritionFacts2.setSodium(240);
nutritionFacts2.setCarbohydrate(240);
遗憾的是，JavaBeans模式自身有严重的缺点。因为构造过程被分到了几个调用中，在构造过程中JavaBean可能处于不一致的状态。类无法仅仅通过检验构造器参数的有效性来保证一致性，因此它调式起来十分困难。与此相关的另一点不足在于，JavaBeans模式阻止了把类做成不可变的可能（见第15条），这就需要程序员付出额外的努力来确保它的线程安全。
当对象的构造完成，并且不允许在解冻之前使用时，通过手工“冻结”对象，可以弥补这些不足，但是这种方式十分笨拙，此外，他还会在运行时导致错误，因为编译器无法确保程序员会在使用之前先在对象上调用freeze方法
方式三：Builder模式
既能保证像重叠构造器那样的安全性，也能保证像JavaBeans模式那么好的可读性。不直接生成想要的对象，而是让客户端利用所有必要的参数调用构造器，得到一个builder对象。然后客户端在builder对象上调用类似于setter的方法，来设置每个相关的可选参数。最后，客户端调用无参构造器build方法来生成不可变的对象。这个builder是它构建的类的静态成员类（见22条）。下面是它的示例：
/**
* @author: Hashub小晖
* @WeChat: NGSHMVP
* @Date: 2018/9/30 21:37
* @function:Builder模式 Builder Pattern
*/
public class NutritionFacts3
{
public final int servingSize;//(ml)require
public final int servings;//(per container)require
public final int calories;//optional
public final int fat;//(g)optional
public final int sodium;//(mg)optional
public final int carbohydrate;//(g)optional
/**
* 静态内部类Builder
*/
public static class Builder
{
//Require 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 carbohydrate = 0;
private int sodium = 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 carbohydrate(int val)
{
carbohydrate = val;
return this;
}
public Builder sodium(int val)
{
sodium = val;
return this;
}
public NutritionFacts3 build()
{
return new NutritionFacts3(this);
}
}
private NutritionFacts3(Builder builder)
{
servingSize = builder.servingSize;
servings = builder.servings;
calories = builder.calories;
fat = builder.fat;
sodium = builder.sodium;
carbohydrate = builder.carbohydrate;
}
}
NutritionFacts3是不可变的，所有的默认参数值都单独放置一个地方。
builder的setter方法返回builder本身，以便可以把调用链接起来。下面是客户端代码：
new Builder(240, 8)
.calories(100)
.sodium(35)
.carbohydrate(27)
.build();
builder像个构造器一样，可以对其参数强加约束条件。build方法可以检验这些约束条件。将参数从builder拷贝到对象中之后，并在对象域而不是builder域（见39条）中对它们进行简阳。如果违反了任何约束条件，build方法就应该抛出IllegalStateException（见60条）。异常的详细信息应该显示出违反了哪个约束条件（见63条）。
对多个参数加约束条件的另一种方法是：用多个setter方法对某个约束条件必须持有的所有参数进行检查。乳沟该约束条件没有得到满足，setter方法就会抛出IllegalArgumentException。，一旦传递了无效的参数，立即就会泛型约束条件失败，而不是等着调用build方法。
与构造器相比，builder的略微优势在于，builder可以有多个可变（varargs）参数。构造器就像方法一样，只能有一个可变参数。因为builder利用单独的方法来设置每个参数，直到每个setter方法都有一个可变参数。
Builder模式十分灵活，可以利用单个builder构建多个对象。builder的参数可以在任何创建对象期间进行调整，也可以随着不同的对象而改变。builder可以自动填充某些域，例如每次穿对象时自动增加序列化。
设置了参数的builder生成了一个横好的抽象工厂（Abstract Factory），客户端可以将这一一个builder传给方法，使该方法能够为客户端创建一个或多个对象。使用泛型可以满足所有的builder，无论它们在构建哪种类型的对象：
//A builder for object of type I
public interface Builder1<T>
{
public T build();
}
注意，可以声明NutritionFacts.Builder类来实现Builder
带有Builder实例的方法通常利用有限制的通配符类型（bounded wildcard type）来约束构建器的类型参数。例如，下面就是构建每个节点的方法，它利用一个客户端提供的Builder实例来构建树：
Tree buildTree(Builder<? extends Node>nodeBuilder)
{
.....................
}
Builder模式的确有它自身的不足。为了创建对象，必须先创建它的构建器。虽然创建构建器的开销在实践中可能不那么明显，但是在某些十分注重性能的情况下，可能就成问题了。Builder模式还比重叠构造器更加长，因此它只在有很多参数的时候才使用。如果一开始就使用构造器或者静态工厂，等到类需要多个参数时才添加构建器，就会无法控制，那些过时的构造器或者静态工厂显得十分不协调。因此，通常最好一开始就使用构建器。
简而言之，如果类的构造器或者静态工厂中具有多个参数，设计这种类时，Builder模式就是不错的选择，特别是当大多参数都是可选的时候。与使用的重叠构造器模式相比，使用Builder模式的客户端代码将更加易于阅读和编写，构建器也比JavaBeans更加安全。
网友评论