静态工厂和构造函数都有一个限制：可选参数数量很大时，他们都不能很好地扩展。考虑一下这个例子：用一个类来表示袋装食品上的营养成分标签，这些标签有几个必选字段：每份的含量、每罐的份数、每份的卡路里；还有超过20个可选字段：总脂肪含量、饱和脂肪含量、转化脂肪含量、胆固醇含量、钠含量等等。大多数产品只有少数几个可选字段是非零值。
你将为这种类编写怎样的构造函数或者静态工厂呢？程序员习惯上会使用telescoping constructor模式，提供一个值包含必选参数的构造函数，以及一个包含一个可选参数的构造函数、一个包含二个可选参数的构造函数、等等，最后一个构造函数包含所有可选参数。【例】就像下面的示例那样，简单起见，我们只展示4个可选参数的情况。
// 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; // optional
private final int fat; // (g) optional
private final int sodium; // (mg) optional
private 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);
}
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个参数，这看起来也还不算太糟，但是随着参数数目增长，很快就会无法控制。 简言之，telescoping constructor模式虽然可行，但是当参数过多时就很难编写客户端代码，而且更加难以阅读。读者会奇怪这些参数都表示什么含义，必须仔细地数着参数才能弄明白。一长串类型相同的参数会导致微妙的bug。如果客户端意外弄反了两个参数的顺序，编译器不会报错，但是程序在运行时会出现错误的行为（Item40）。
遇到多个构造函数参数的第二种方法是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; // " " " "
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模式自身有重大缺陷。由于构造过程分成了多个调用，在构建过程中JavaBean可能处于不一致状态。类不能通过检查构造函数参数的有效性来保证一致性。如果尝试使用处于不一致状态的对象，就会导致错误，而且产生这些错误的代码大相径庭，导致很难调试。相关的另一个缺点是，JavaBean模式阻止了把类变为“不可变”（Item15）的可能性，而且要求程序员付出额外努力来保证线程安全。
有一种办法可以降低这个缺点：当对象构建完成后，手工“冻结”该对象，并且不允许使用未冻结的对象。不过这种方法不灵便，在实践中很少使用。更重要的是，由于编译器不能确保程序员在使用对象前先调用其冻结方法，所以这种方法可能导致运行时错误。
幸运的是，还有第三种方法结合了telescoping constructor模式的安全性以及JavaBeans模式的可读性。这是Builder模式的一种形式。客户端并不直接构造需要的对象，而是先调用一个包含所有必选参数的构造函数（或静态工厂），得到一个builder object；然后，客户端在该builder object上调用类似setter的方法来设置各个感兴趣的可选参数；最后，客户端调用无参数的build方法生成对象（不可变对象）。——build相当于冻结方法
builder是所要构建的类的一个静态成员类（Item22）。【例】如下是它的示例：
//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{
//必选参数
private final int servingSize;
private final int servings;
//可选参数
private final int calories = 0;
private final int fat = 0;
private final int carbohydrate = 0;
private final int sodium = 0;
//Builder构造函数设置所有必选参数
public Builder(int servingSize, int servings){
this.servingSize = servingSize;
this.servings = servings;
}
//Builder类setter方法设置可选参数
public Builder calories(int v){
this.calories = v;
return this;
}
public Builder fat(int v){
this.fat = v;
return this;
}
public Builder carbohydrate(int v){
this.carbohydrate = v;
return this;
}
public Builder sodium(int v){
this.sodium = v;
return this;
}
//builde()返回需要构建的对象
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是不可变的（未提供setter方法），并且所有的参数值得默认值都放在一个地方。builder的setter方法返回builder自身，所以setter的调用可以链接起来。客户端代码就像下面这样：
NutritionFacts coca = new NutritionFacts.Builder(240,8) .calories(100).sodium(35).build();
这种客户端代码易于编写，而且更重要的是易于阅读。Builder模式模拟了Ada和Python中的具名可选方法（named optional parameters）。
对多个参数强加约束的另外一种方法是，在setter方法中包含约束要求的所有参数。如果约束不满足，则setter抛出IllegalArgumentException。这种方法的优点是能在非法参数传入时及时发现约束失败，而不必等到调用build()才会发现。
builder比构造函数的另一个小优点是它能有多个varargs方法参数，而构造函数与普通方法一样只能有一个varargs方法参数。由于builder用独立的方法来设置每个参数，所以你想要多少个varargs方法参数，他们就能有多少个varargs方法参数，最多可以每个setter都有一个varargs方法参数。
Builder模式是很灵活的，一个builder可用来构建多个对象。builder的参数可以再创建对象过程中进行调整以便改变对象。Builder可以自动填写某些字段，例如每次创建对象时自动增加的序列号字段。
设置了参数的builder是一个很好的抽象工厂（Abstract Factory），换句话说，客户端可以将这种builder传给一个方法，然后该方法为客户端创建一个或者多个对象。如果要这么做，你需要有一个类型来代表这个builder，如果你在用JDK1.5或之后的版本，那一个泛型类型（Item26）就能满足所有的builder，而不需考虑他们构建的对象类型是什么。
//A builder for objects of type T
public interface Builder<T>{
public T build();
} 注意NutritionFacts.Builder类需要实现接口Builder<NutritionFacts>。
带有Builder示例的方法通常限制builder的类型参数使用一种有限制的通配符类型（bounded wildcard type, Item28）。【例】例如，下面是一个构建Tree示例的方法，使用客户端提供的Builder示例来创建每个节点。
Tree buildTree(Builder<? extens Node> nodeBuilder){...} 【例】Java中Class对象是抽象工厂的一个典型实现，其newInstance()方法充当部分build()方法。
private T newInstance0()
throws InstantiationException, IllegalAccessException
{
...
Constructor<T> tmpConstructor = cachedConstructor;
// Security check (same as in java.lang.reflect.Constructor)
int modifiers = tmpConstructor.getModifiers();
if (!Reflection.quickCheckMemberAccess(this, modifiers)) {
Class caller = Reflection.getCallerClass(3);
if (newInstanceCallerCache != caller) {
Reflection.ensureMemberAccess(caller, this, null, modifiers);
newInstanceCallerCache = caller;
}
}
// Run constructor
try {
return tmpConstructor.newInstance((Object[])null);
} catch (InvocationTargetException e) {
Unsafe.getUnsafe().throwException(e.getTargetException());
// Not reached
return null;
}
} 这种用法隐含着许多问题，newInstance()方法总是尝试去调用类的无参数构造函数，而这个构造函数也许根本不存在。这种情况下你根本不会看到编译期错误，而在运行时客户端代码必须处理InstantiationException或者IllegalAccessException，这样既不美观也不方便。同样，newInstance()方法会传播无参数构造函数的所有异常，即便newInstance()没有写对应的throws字句。换句话说，Class.newInstance破坏了编译期异常检测。而上文提到的Builder接口，则改正了这些不足。Builder模式当然也有缺点。1）为了创建一个对象，你必须首先创建它的builder。虽然创建builder的开销在实践中可能不那么明显，但在某些注重性能的情况下可能会有问题。2）Builder模式比telescoping constructor模式要更冗长，所以只有当参数足够多时才应该使用它，比如4个或更多。不过，要记住你在将来也许会想增加参数，如果你一开始就使用构造函数或静态工厂，那当参数数目失控时就得增加builder了，此时被废弃的构造函数或静态工厂就会像个怪物一样杵在那儿。所以，通常最好一开始就使用builder。
总之，当所设计的类的构造函数或静态工厂拥有过多参数时，Builder模式是个不错的选择，尤其当大多数参数时可选的时候。与传统的telescoping constructor模式相比，使用builder模式客户端代码会更加易读更加易写；同时builder比JavaBeans模式更安全。