Java方法参数太多怎么办—Part3—Builder模式

本文由 ImportNew - 韩远青 翻译自 dzone。欢迎加入翻译小组。转载请参见文章末尾的要求。

目录

自定义类型
引入参数对象
Builder模式

本文是这个系列的第三篇文章，介绍了通过Builder模式应对参数过多的问题。如果你也希望参与类似的系列文章翻译，可以加入我们的Java开发 和 技术翻译 小组。

在前两篇文章中，我分别使用了自定义类型和参数对象方法来减少构造器或方法调用传入的参数数量。本文关注的是Builder模式。我认为它不仅能够帮助构造函数“瘦身”，甚至可以对非构造函数也能发挥同样的作用。

在Effective Java第二版中，Josh
Bloch在第二章中就提到使用Builder模式处理需要很多参数的构造函数。他不仅展示了Builder的使用，也描述了相这种方法相对使用带很多参数的构造函数带来的好处。在本文的结尾我将进一步总结Builde模式的优点。需要指出的是Josh Bloch已经在他的书本贯穿了这一思想。

为了说明这种方法的优点，我会继续使用Person类。需要指出的是，为了更好地聚焦于类构造本身我只添加了个别方法。

Person.java （非Builder模式）

这样写的类构造器也无可厚非，但当有许多参数时编写客户端代码会很困难。这时，如果使用Builder模式会有效提高代码的可读性。在我的博客中曾写过使用NetBeans能方便地实现代码重构。下面就是使用NetBeans重构过的代码。

PersonBuilder.java

相对于之前的写法，我更趋向于将builder作为它构建类的静态成员类（嵌套类）。即便是NetBeans自动生成的Builder使用起来也很方便。另一个区别在于，我希望Builder实现一个包含了必要字段的构造函数，而不是一个无参构造函数。

下面显示的是改进后的代码。

Person.java[b]（Person.Builder嵌套类）[/b]

使用Builder模式时，如果结合我前两篇文章介绍的自定义类型和参数对象方法一起使用效果会更好。示例代码如下。

Person.java （嵌套类Builder，自定义类型加参数对象）

最后2段代码列表展示了Builder构建对象的常见方法。实际上，《在Effective Java 第二版》第2条中就是用Builder来创建和销毁对象。此外，Builder能更简单地通过参数对象传递间接实现了一个非构造函数方法。在上面最后一段代码中，这些方法都接收了一些参数对象。诚然，即使使用了Builder构建参数对象还是比较枯燥的。但每一次Builder构建都是间接让非构造函数方法受益，因为参数对象使用确实有效减少了方法参数的数量。

下面重新定义的FullName和Address类既能做参数本身也使用了Builder模式。

FullName.java（使用Builder）

Address.java （使用Builder）

由于用了Builder，新的Person实例可以通过下面这种方式创建。当然为了比较，也给出了传统的Person实例化方法。

实例化Person（不使用Builder）

final person = new Person(“Coltrane”, “Rosco”, “Purvis”, null, “Hazzard”, “Georgia”, false, true, true);

看完代码高下立判，调用传统JAVA构造器的客户端代码的可读性远不如使用了Builder的客户端代码。同一类型的变量和空放置在一起被调用将会导致一些微妙的错误。（试想，如果客户端不小心颠倒了其中的几个参数顺序，编译不会出错但在运行时肯定出错）

Builder模式好处和优点

使用Builder模式必然会导致写两遍相关属性的代码和SETTER方法，看起来有点吃力不讨好。然而需要看到的是，客户端代码的可用性和可读性得到了大大提高。与此同时，构造函数的参数数量明显减少调用起来非常直观。

Builder方法另外一个优势在于，单个builder构建多个对象时Builder参数可在创建期间进行调整，还可以根据对象不同而进行改变。这就像我越来越推崇的以“不变”应“万变”。Builder模式特别适合那些属性个数很多的类，我认为没有必要给那些本不需要设置值传递参数（设置null）。

Builder模式在提高代码可读性的同时，使用IDE提供的代码补全功能也更加容易。Builder模式在与构造函数一起使用带来的更大优势在Josh
Bloch的Effective Java第二版第2条中有详细阐述。

Builder模式的代价和缺点

使用Builder模式是肯定会增加代码量的。此外，尽管客户端的代码可读性明显改善，但随之而来的客户端代码变得更加冗长。我还是坚持这一观点：相比较参数数量的增加，相同类型的参数混在一起，可选参数的增加而言，改善代码可读性更有价值。

Builder会增加个类代码，这也意味着开发者在给类增加属性时有时会忘记给该属性添加支持的builder。为了克服这个问题，通常我会将builder嵌套到类中，这样可以很容易地发现哪个相关的builder需要更新。尽管忘记的风险依旧存在，但是这风险就像忘记给类的新属性增加 toString()、 equals(Object)、 hashCode()或其他类基于是所有属性的方法一样。

在我的Builder实现中，我会用Builder的构造函数而不是set方法传递客户需要的属性。这样做的好处在于，对象总是能被一次完整的实例化，而不是靠开发人员调用时用set方法补充额外的属性完成实例化。这也体现了不可变性带来的好处。然而，相应地也会造成自己设定的属性方法可读性降低。

正如它名字表示的那样，Builder只是一个替代构造器的选择不能直接用于降低非构造函数方法的参数数量，但是结合参数对象的使用就能达到这一点。有关更多反对用Builder来进行对象构建的讨论可以参见 A dive into the Builder pattern上的相关评论。

总结

构建对象时，如果碰到类有很多参数——其中很多参数类型相同而且很多参数可以为空时，我更喜欢Builder模式来完成。当参数数量不多、类型不同而且都是必须出现时，通过增加代码实现Builder往往无法体现它的优势。在这种情况下，理想的方法是调用传统的构造函数。再者，如果不需要保持不变，那么就使用无参构造函数调用相应的set方法吧。