遇到多个构造器参数时要考虑使用构建——《effective Java》

       静态工厂和构造器有个共同的局遇到多个构造器参数时要考虑使用构建器限性：它们都不能很好地扩展到大量的可选参数。因此，对于解决这一类问题，程序员一向习惯采用重叠构造器（telescoping constructor）模式，在这种模式下，提供的第一个构造器只有必要的参
数，第二个构造器有一个可选参数，第三个构造器有两个可选参数，依此类推，最后一个构
造器包含所有可选的参数。重叠构造器模式虽然可行，但是当有许多参数的时候，客户端代码会很难编写，并且仍然较难以阅读。

      与构造器相比，builder 的微略优势在于，它可以有多个可变（varargs）参数。因为builder 是利用单独的方法来设置每一个参数。此外，构造器还可以将多次调用某一个方法而传人的参数集中到一个域中，如前面的调用了两次 addTopping 方法的代码所示。Builder 模式十分灵活，可以利用单个 builder 构建多个对象。builder 的参数可以在调用build 方法来创建对象期间进行调整，也可以随着不同的对象而改变。builder 可以自动填充某些域，例如每次创建对象时自动增加序列号。
Builder 模式的确也有它自身的不足。为了创建对象，必须先创建它的构建器。虽然创建这个构建器的开销在实践中可能不那么明显，但是在某些十分注重性能的情况下，可能就成问题了。Builder 模式还比重叠构造器模式更加冗长，因此它只在有很多参数的时候才使用，比如 4 个或者更多个参数。但是记住，将来你可能需要添加参数。如果一开始就使用构造器或者静态工厂，等到类需要多个参数时才添加构造器，就会无法控制，那些过时的构造器或者静态工厂显得十分不协调。因此，通常最好一开始就使用构建器。简而言之，如果类的构造器或者静态工厂中具有多个参数，设计这种类时，Builder模式就是一种不错的选择，特别是当大多数参数都是可选或者类型相同的时候。与使用重叠构造器模式相比，使用 Builder 模式的客户端代码将更易于阅读和编写，构建器也比JavaBeans 更加安全。