第2条：遇到多个构造器参数时要考虑使用构建器

        静态工厂和构造器有个共同的局限性：它们都不能很好地扩展到大量的可选参数。比如用一个类表示包装食品外面显示的营养成分标签。这些标签中有几个域是必需的：每份的含量、每罐的含量以及每份的卡路里。还有超过20个的可选域：总脂肪量、饱和脂肪量、转化脂肪、胆固醇、钠等等。大多数产品在某几个可选域中都会有非零的值。

        对于这样的类，应该用哪种构造器或者静态工厂来编写呢？程序员一向习惯采用重叠构造器（telescoping constructor)模式，在这种模式下，提供的第一个构造器只有必要的参数，第二个构造器有一个可选参数，第三个构造器有两个可选参数，依此类推，最后一个构造器包含所有可选的参数。下面有个示例，为了简单起见，它只显示四个可选域：

//Telescoping constructor pattern does not scale well!
public class NutritionFactsprivate{
    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;
    }
}

        这个构造器调用通常需要许多你本不想设置的参数，但还是不得不为它们传递值。在这个例子中，我们给fat传递了一个值为0。如果“仅仅”是这6个参数，看起来还不算太糟糕，问题是随着参数数目的增加，它很快就失去了控制。

        遇到许多可选的构造器参数的时候，还有第二种代替办法，即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模式使得把类做成不可变的可能性不复存在，这就需要程序员付出额外的努力来确保它的线程安全。

        幸运的是，还有第三种替代方法，它既能保证像重叠构造器模式那样的安全性，也能保证像JavaBeans模式那么好的可读性。这就是建造者(Builder)模式[Gamma95]的一种形式。它不直接生成想要的对象，而是让客户端利用所有必要的参数调用构造器（或者静态工厂)，得到一个builder对象。然后客户端在builder对象上调用类似于setter的方法，来设置每个相关的可选参数。最后，客户端调无参的build方法来生成通常是不可变的对象。这个builder通常是它构建的类的静态成员类。下面就是它的示例：

//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();

        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();
    }
}
        

        这里有两个具体的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(Builderbuilder) {
        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.Bui1der的build方法返回NyPizza,而Calzone.Builder中的则返回Calzone。在该方法中，子类方法声明返回超级类中声明的返回类型的子类型，这被称作协变返回类型(covariant return type)。它允许客户端无须转换类型就能使用这些构建器。

        这些“层次化构建器”的客户端代码本质上与简单的NutritionFacts构建器一样。为了简洁起见，下列客户端代码示例假设是在枚举常量上静态导入：

NyPizza pizza = new NyPizza.Builder(SMALL)
        .addTopping(SAUSAGE).addTopping(ONION).build();
Calzonecalzone = new Calzone.Builder()
        .addTopping (HAM).sauceInside().build();

        与构造器相比，builder的微略优势在于，它可以有多个可变(varargs)参数。因为builder是利用单独的方法来设置每一个参数。此外，构造器还可以将多次调用某一个方法而传入的参数集中到一个域中，如前面的调用了两次addTopping方法的代码所示。

        Builder模式十分灵活，可以利用单个builder构建多个对象。builder的参数可以在调用bui1d方法来创建对象期间进行调整，也可以随着不同的对象而改变。builder可以自动填充某些域，例如每次创建对象时自动增加序列号。

        Builder模式的确也有它自身的不足。为了创建对象，必须先创建它的构建器。虽然创建这个构建器的开销在实践中可能不那么明显，但是在某些十分注重性能的情况下，可能就成问题了。Builder模式还比重叠构造器模式更加冗长，因此它只在有很多参数的时候才使用，比如4个或者更多个参数。但是记住，将来你可能需要添加参数。如果一开始就使用构造器或者静态工厂，等到类需要多个参数时才添加构造器，就会无法控制，那些过时的构造器或者静态工厂显得十分不协调。因此，通常最好一开始就使用构建器。

        简而言之，如果类的构造器或者静态工厂中具有多个参数，设计这种类时，Builde模式就是一种不错的选择，特别是当大多数参数都是可选或者类型相同的时候。与使用重叠构造器模式相比，使用Builder模式的客户端代码将更易于阅读和编写，构建器也比JavaBeans更加安全。