静态工厂方法和构造器，它们都不能很好的扩展到大量的可选参数。

重叠构造器

当参数过多时可以采用重叠构造器（telescoping constructor）模式，类有多个重载的构造函数，但是当有许多参数的时候，客户端代码会很难编写，且难以阅读。

JavaBeans 模式

在这种模式下，调用一个无参构造器来创建对象，然后调用 setter 方法来设置每个参数。
这种模式弥补了重叠构造器模式的不足。说的明白一点，就是创建实例很容易，产生的代码读起来也很容易。

不过，JavaBeans 模式自身有很严重的缺点。因为构造过程被分到了几个调用中，在构造过程中 JavaBean 可能处于不一致的状态。类无法仅仅通过检验构造器参数的有效性来保证一致性。试图使用处于不一致状态的对象，将会导致失败。JavaBeans 模式阻止了把类做成不可变的可能，并需要确保它的线程安全。

Builder模式

Builder 模式，既能保证像重叠构造器模式那样的安全性，也能保证像 JavaBeans 模式那么好的可读性。

不直接生成想要的对象，而是让客户端利用所有必要的参数调用构造器（或者静态工厂），得到一个 Builder 对象。然后客户端在 builder 对象上调用类似于 setter 的方法，来设置每个相关的可选参数。最后，客户端调用无参的 build 方法来生成不可变的对象。这个 builder 是他构建的类的静态成员类。

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

    // 使用方式
    public static void main(String[] args) {
        NutritionFacts cocaCola = new NutritionFacts.Builder(240, 8).calories(100)
        .sodium(35).carbohydrate(27).build();
        System.out.println(cocaCola);
    }
}

这样的客户端代码很容易编写,更为重要的是，易于阅读。builder 模式模拟了具名的可选参数

具名的可选参数，类似 Python 中关键字参数，可以参考：http://www.cnblogs.com/similar/p/5006705.html

就像构造器那样，builder 可以强加给它的参数变量，build 方法实例化实体类，实例化前，可以对参数进行检查，如果不满足条件的，应该抛出 IllegalStateException，或者其他自定义异常。

另外一个小优点是 builder 可以有多个可变参数。构造器，像方法一样，可能只有一个可变参数。因为 builder 用不同的方法设置参数，只要你喜欢，他们可以有很多可变参数。

泛化建造者模式

泛化建造者模式（Abstract Factory）
通过生命静态工厂方法的返回值为父类型来实现。用泛型让建造者模式和抽象工厂模式融合：

// A builder for objects of type T
public interface Builder<T> {
    public T build();
}

这里我们的 NutritionFacts.Builder 类应该这样来声明实现：Builder。

类层次结构

Builder 模式非常适合类层次结构。使用平行层次的 builder，每个嵌套在相应的类中。抽象类有抽象的 builder；具体的类有具体的 builder。例如，考虑代表各种比萨饼的根层次结构的抽象类：

// Builder pattern for class hierarchies
import java.util.EnumSet;
import java.util.Objects;
import java.util.Set;

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 是一个带有递归类型参数（ recursive type parameter）（详见第 30 条）的泛型类型。这与抽象的 self 方法一起，允许方法链在子类中正常工作，而不需要强制转换。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 方法所演示的那样。

Java 中传统的传统的抽象工厂是 Class 对象，它用 newInstance 方法充当 build 方法的一部分，newInstance 默认会调用类的无参构造函数，但是这个类的无参构造函数可能根本不存在，而且可怕的是你不会受到编译期的错误，你必须在运行期对异常进行处理。相反，使用 Builder 模式，在编译器就能知道出错了。

劣势：为了创建一个对象，必须先创建一个 builder，可能在某些情况下会有性能问题。并且它应该并用于有四个或者更多的参数时，否则应该用 telescoping constructor 的形式（即，构造器传参的形式）。但是你需要记住未来的扩展情况。

总之，当类的参数过多的时候，Builder 模式是一个不错的选择。用 Builder 的模式，对传统的 telescoping constructor 模式而言，客户端代码更容易阅读和书写；比 JavaBeans 模式更加的安全。