Java方法参数太多怎么办—Part8—使用工具

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

目录

1. 自定义类型
2. 引入参数对象
3. Builder模式
4. 重载
5. 方法命名
6. 方法返回值
7. 可变状态变量
8. 使用工具

本系列前七篇文章讲述了解决Java方法参数过多的问题。本文主要聚焦于通过各种方式减少方法参数。在本系列第八篇文章中，我研究了如何甄别哪些Java方法的参数过多以及可以帮助解决这种情况的工具。

方法参数多少才算多？这个问题没有一个明确的答案。答案不仅取决于个人判断，而且或多或少取决于参数本身的性质：它们是什么？它们使用的是自定义类型，还是基本类型或者重复相同的类型类型？是否有参数可以传入null？ Robert Martin在Clean Code第四十页写到：

函数参数的理想个数是零，其次是一，紧随其后的是二，应该尽可能避免三个参数的情况。参数如果多于三个则需要特殊的理由，而且无论如何都不应该再使用。

Steve McConnell在Code Complete中写到：开发者应该限制参数在七个以内，因为“人们认为七是一个有魔力的数字”。我不认为该数字有确切的最大数值，而且看起来七也不像是一个很少被超过的经验值。通常我更喜欢Martin推荐的做法，即少于三个参数。

“视力测试”

在谈到运动赛事时，有一个普遍的观点：某队员或者某团队没有通过“视力测试”（The Eye Test）。对此我的理解是，无论关于该队员或团队有什么优异的数据，观看过比赛的人都认为他们的表现与数据描述很不相称。换句话说，在某种程度上很难以数据描述它们，观众感觉他们的技术不如传闻般精湛。 在很多方面软件开发都有自己的“视力测试”。当某些事情与“规则”相比更好或更差时，它们（视力测试）会告诉我们真实的情况。除此之外，正如在可以运动赛事中将数据与运动员的客观表现进行对比，我们仍然有一些“规则”或指导方针可以判断哪些是好的软件开发习惯。例如，我们可能会说在软件中“参数当然越少越好”。工具的最大局限性在于，不能为我们扮演一个“视力测试”者。然而，工具可以帮助我们辨别可以改进的地方。换句话说，工具可以帮助报告游戏或比赛“数据”。尽管如此，我们必须经过根据工具报告的结果自行判断。

静态分析工具

静态分析工具可自动辨别方法或构造器参数过多的情况。一旦识别出参数过多，开发者可以对他们应用“视力测试”来决定是否需要纠正。

PMD

PMD是一个支持多语言（包括Java）的源代码编程漏洞分析工具，它的口号是“不要迁怒于用户”。PMD的规则之一是“ExcessiveParameterList，过长的参数列表”（在PMD4.3版本中，使用“LongParameterListRule，长参数列表规则”表示）。当该规则触发时，PMD会试图把许多参数封装成为一个包含它们的对象传递过去（详见参数对象）。PMD最新的文档写道：“冗余的方法参数对代码维护来说是一个挑战，当其中的大多数数据类型相同时尤其如此”。这些情况通常意味着需要新对象来封装过多的参数。 对于“过多”的程度，任何工具必须给出一个确定的数字。例如在PMD中，默认的数字是10。显然，触发PMD“过长的参数列表”规则的最小数字已经超过Steve McConnell推荐的7个，并且远高于Robert Martin建议的不超过3个。 NetBeans可以通过安装PMD插件获得该支持，也可以通过Software Quality Environment安装PMD插件。关于后者，我曾在NetBeans 7 and Software Quality Environment和Configuring SQE Plugins in NetBeans 7文章里讲过。QAPlug-PMD是一个提供类似功能的IntelliJ IDEA的插件，PMD Eclipse则是一个专门为Eclipse设计的PMD插件。

Checkstyle

与PMD类似，Checkstyle能够检测方法和构造器参数是否过多并给出警告。在它的主页上，Checkstyle被定义为“一种帮助程序员遵循按照某种编码标准编写Java代码的开发工具”。特别地，Checkstyle支持参数个数的检查——检查方法和构造器的参数个数。在Checkstyle中，方法和构造器默认的最大参数个数是7（与Steve McConnell推荐的一样）。 Checkstyle可以通过Checkstyle Beans插件在NetBeans中使用。与NetBeans PMD类似，Checkstyle在NetBeans中也可以通过先前提到的Software Quality Environment安装。Eclipse和IntelliJ IDEA.中的支持Checkstyle的插件分别是eclipse-cs插件和Checkstyle-IDEA。

CodePro Analytix

CodePro Analytix是谷歌Java开发工具的一部分，并被描述为“为追求高质量软件和努力减少开发代价和周期的Eclipse开发者而准备，号称是最早的Java软件测试工具”。它包括带有一种规则即“程序复杂度”的代码审计能力。这些规则之一是“长参数列表”规则。概括地说，该规则就是“方法不该有太多的参数”。它的描述是：“这个审计规则发现传参个数大于规定数目的方法。超过该数目的方法可能太复杂。可以考虑将一些值和与它们相关的行为移到一个独立的类当中。CodePro Analytix也支持一种“参数平均数”规则，不过它没有任何意义。这种规则报告每个方法的平均参数个数，但是并不包含构造器。

NetBeans的Java代码衡量标准提示

我已经提到NetBeans中为了Checkstyle和PMD的插件，但在NetBeans中我最喜爱的功能之一则是大量、高定制化的内置提示和检查。NetBeans 7.4引入了一种全新的提示，叫做“Java代码度量标准”。其中之一便是“构造器声明太多参数” 提示。关于这个提示的描述：“报告带有太多参数的构造器。构造器通常带有比常规方法多的参数，特别是当初始化一个较大的对象时。大量参数只是表明这是一个糟糕的设计。这是可能的，即将来添加更多的参数，像生成器这样的创建模式应该作为考虑对象。”在本系列上一篇文章中，我讲述了生成器模式的应用，甚至讨论了如何使用NetBeans来重构一个生成器。

另一个新加的提示——“方法声明太多参数”被描述为“报告带有太多参数的方法。参数过多表明这是一个糟糕的设计。这是可能的，即将来添加更多的参数，应该将参数封装在一个Command对象中，但它提高了维护成本。另外，一个方法能够被重构为几个其它方法，每个新方法均可以完成原始方法的部分功能并且只需要传递较少的参数。”这个被推荐的方式本质上与我本系列早前的博文讲的参数对象方式相同。

在NetBeans 7.4中，“Java代码度量”所有提示默认都是不可用的。在他的博文”Just How Messed Up Is My Code?“中，这个“偶然”的NetBeans博客Geertjan Wielenga演示了如何配置Java代码度量并使之生效。 下面的屏幕截图演示了NetBeans 7.4中的Java编码标准的使用方法。

这可以通过 “源（Source）” 菜单，然后 “检查…（Inspect…）”子菜单（这将打开NetBeans 7.4的“检查（Inspect）”窗口）：

当“检查（Inspect）”窗口中与“使用（Use）”标签中的“配置（Configureation）”单选按钮相邻的下拉菜单被选中时，下面截图中表示的选项才是可以使用的。

出于演示的目的，我选择“所有分析器（All Analyzes）”，然后单击“检查（Inspect）”按钮。下面的屏幕截图演示了检验/分析正在进行中……

“开箱即用”的NetBeans检查机制发现我的一堆没有Javadoc报表的代码，但却并未标出带有太多参数的构造器和方法。为了说明这一点，我需要依照Geertjan的博文中的步骤来。这样做，单击源（Source）|检查（Inspect），然后选择“默认（Default）”进行“配置（Configuration）”。

现在选择“默认（Default）”后，我可以单击“管理…（Manager…）”按钮，紧接着会出现“配置（Configuration）”窗口。

单击“默认（Default）”标签选择下拉选项“新建…（New…）”，出现如下窗口：

我可以为新的“Java编码标准”配置进行命名了。

单击分析器旁的下拉菜单，选择“NetBeans Java提示”，所有的NetBeans Java提示选项以目录的形式罗列出来。如下图所示：

下面的截图表明我可以选择“构造器声明太多参数”和“方法声明太多参数”：

在新的“Java代码度量”检查下，现在很容易通过单击“检查（Inspect）”按钮来检查那些特殊的担心：

单击“检查（Inspect）”按钮来应用新建的“Java代码度量”检查，导致下面的截图出现。第一幅图显示了高水平的结果，第二幅图展示了在高水平结果中单击后出现的更多专门的细节：

在上述我所陈述的静态分析工具的帮助下，我们可以调整被视为构造器和方法的“（参数）太多”的数目。这个配置在NetBeans的Java代码度量支持下真的很容易。下面两个截图分别展示了我们选择想要检查的同一窗口选项后出现的为构造器和方法设置的值。每个选项的扩展窗口包含了检查类型的定义和一个选择可使用的参数个数的区域。

能够改变被认为不可接受的参数数目（或者至少值得指出的是：这样可以应用“eye  test”），这真是太好了！因为有很多不同的关于什么数字不可被接受的选项。

正如最后系列的截图所展示的那样，NetBeans 7.4允许我们特别地为有太多参数的方法和构造器检查代码。又正如我在本篇文章的这部分已经写的那样，我被NetBeans以提供显著静态代码分析支持而提醒。

IntelliJ IDEA 检查

IntelliJ IDEA提供深挖出过多参数的方法检查。这个检查被如此描述：“它报告任何带有过多参数方法的实例详情。后者是一个需要重构好信号。继承自库类的方法签名会被该检查机制忽略掉”。该检查允许配置方法的“过多”参数值。

其他的静态分析工具

除了我已经讲述的，还有其它的静态分析工具。通过静态分析，辨别并指出了Java方法和构造器参数过多的情况。这些包括Java Coding Standard Checker和Sonar。所有这些静态分析工具的存在证明了过多的参数对代码的稳定性和后期维护来说会是一个问题。

代码改变工具

目前为止，本篇文章讨论的工具在分析代码和找出存在的被认为参数过多的方法和构造器方面非常有用。一旦定位，我们就可以通过如上述的方法手动减少参数来改变或重构它们。幸运的是，有一些工具可以帮助这些重构和新代码的生成。现代的Java集成开发环境在这方面尤其有用。

重构

解决构造器过多参数我最钟爱的方法之一是使用生成器。幸运的是，NetBeans提供一种将依赖众多参数的构造器改为使用一个生成器，并实现自动重构代码的能力。我曾在文章 Builder模式和 NetBeans 7.2: Refactoring Parameterized Constructor As Builder中讲过这个方法。IntelliJ IDEA有一个类似的重构工具叫做“使用生成器改变构造函数（Replace Constructor with Builder）”。Eclipse上也有类似的插件Builder Pattern Eclipse Plugin。

代码生成

对于搞定过多参数问题，我还喜欢编写新的自定义类型和引入参数对象。现代的Java集成开发环境在生成这些类和枚举器样例非常有用。通常只需要几分钟就可以生成一个带有toString方法、hashCode方法和equals方法的完整类的实现。在现代Java集成来发环境和它们的代码生成能力下，一般人不再会为编写自定义类型类和参数对象类会花费大量精力。

总结

本篇的焦点在于，介绍那些能帮助开发者的发现以及解决参数过多问题的静态分析工具，能够快速辨别构造器和方法的参数过多问题的静态分析工具与集成开发环境以及现代Java IDE。使重构与代码生成快速和简单。这些针对参数过多问题的工具提醒着我们：事实上这个问题是值得修复的。