（转）第2条：遇到多个构造器参数时要考虑用构建器
????? 静态工厂和构造器有个共同的局限性：它们都不能很好地扩展到大量的可选参数。考虑用一个类表示包装食品外面显示的营养成份标签。这些标签中有几个域是必需的：每份的含量、每罐的含量以及每份的卡路里，还有超过20个可选域：总脂肪量、饱和脂肪量、转化脂肪、胆固醇、钠等等。大多数产品都只有几个可选域中会有非零的值。
对于这样的类，应该用哪种构造器或者静态方法来编写呢？程序员一向习惯采用telescoping constructor模式，在这种模式下，你提供一个只有必要参数的构造器，第二个构造器有一个可选参数，第三个有两个可选参数，依此类推，最后一个构造器包含所有可选参数。下面有个示例，为了简单起见，它只显示四个可选域：
?
????? 这种模式不具备telescoping constructor模式的任何缺点。说得明白一点，就是创建实例很容易，这样产生的代码读起来也很容易：
?
NutritionFacts cocaCola = new NutritionFacts.Builder(240, 8).calories(100).sodium(35).carbohydrate(27).build();?
???? 这样的客户端代码很容易编写，更为重要的是，易于阅读。builder模式模拟了具名的可选参数，就像Ada和Python中的一样。
????
???? Builder模式的确也有它自身的不足。为了创建对象，必须先创建它的构建器。虽然创建构建器的开销在实践中可能不那么明显，但是在某些十分注重性能的情况下，可能就是个问题了。Builder模式还比telescoping constructor模式更加冗长，因此它只在有足够参数的时候才使用，比如4个或者更多个参数。但是记住，将来你可能需要添加参数。如果一开始就使用构造器或者静态工厂，等到类需要多个参数时才添加构建器，就会无法控制，那些过时的构造器或者静态工厂显得十分不协调。因此，通常最好一开始就使用构建器。
???? 简而言之，如果类的构造器或者静态工厂中具有多个参数，设计这种类时，Builder模式就是种不错的选择，特别是当大多数参数都是可选的时候。与使用传统的telescoping constructor模式相比，使用Builder模式的客户端代码将更易于阅读和编写，builders也比JavaBeans更加安全。
?
? 附：原文地址：http://book.51cto.com/art/200901/106048.htm
