java命令行参数工具_Java方法中的参数太多，第8部分：工具-CSDN博客

java命令行参数工具

在我的系列文章的前七篇文章中，有关处理Java方法中期望的参数过多的内容集中在减少方法或构造函数期望的参数数量的替代方法上。在本系列的第八篇文章中，我将介绍一些工具，这些工具可帮助您确定可能存在过多参数的情况，以及有助于在出现这种情况时进行处理的工具。

对于方法或构造函数中过多的参数，实际上并没有硬性规定。在许多方面，这都是一个问题，在一定程度上取决于这些参数是什么，它们是否使用自定义类型而不是原始类型和重复类型，以及是否存在可能需要传递null的可选参数。

罗伯特·马丁（ Robert Martin ）在《清洁代码》中写道（第40页）：

函数的理想参数个数为零（尼拉度）。 接下来是一个（单声道），紧接着是两个（双声道）。 在可能的情况下，应避免使用三个参数（三重性）。 超过三个（多义词）需要非常特殊的理由-因此无论如何都不应使用。

在《代码完成》中，史蒂夫·麦康奈尔（ Steve McConnell）写道，开发人员应“将例程参数的数量限制为七个左右”，因为“七个是让人理解的神奇数字。” 我不认为有任何设定的最大参数数目，但是七个参数似乎似乎很少超过“经验法则”，而且我通常更喜欢较小的数目，例如Martin建议的参数少于三个。

“眼睛测试”

体育谈话和体育写作中有一个共同的表达，即某些球员或球队“没有通过视力测验”。我对这种表达的理解是，这意味着尽管有任何积极的统计数据可能与该球员或团队相关联，但观看球员或团队的比赛会让人们相信他们并不如统计数据所示。换句话说，以一种难以描述的方式，观看者感觉到团队或球员并不像他们的统计数据所暗示的那样熟练。

在许多方面，软件开发都有其自己的“眼力测试”，可以告诉我们某些事情何时比“规则”所暗示的好或坏。尽管如此，我们仍然拥有关于“规则”或一般性指导原则，以了解如何构成良好的软件习惯，就像体育比赛中有统计数据试图客观地对比球队和球员一样。例如，在软件中，我们可能会说“参数较少通常比更多参数要好。” Tooling的最大局限性在于它无法为我们执行“眼力测试”，但可以帮助我们确定潜在的改进领域。换句话说，工具可以帮助报告游戏或比赛的“统计数据”，但是我们必须对工具所报告的内容做出自己的判断（“眼力测试”）。

静态分析工具

静态分析工具可用于自动识别可能期望太多参数的方法或构造函数。一旦确定了可能带有太多参数的方法和构造函数，开发人员便可以对其进行“眼力测试”，以确定是否应采取纠正措施。

PMD

PMD （带有幽默的口号“ Do n't Shoot the Messenger”）是一个“源代码分析器”，可以“发现”多种编程语言（包括Java）中的常见编程缺陷。 PMD的规则之一是“ ExcessiveParameterList ”（PMD 4.3中的LongParameterListRule而不是ExcessiveParameterList ）。触发此规则时， PMD提供的操作是“尝试将参数分组在一起”和“应创建一个新对象以包装大量参数”（请参阅我关于参数对象的文章）。较新的PMD文档这样说：“具有众多参数的方法很难维护，特别是如果大多数方法共享相同的数据类型时。这些情况通常表示需要新对象来包装大量参数。”

任何工具都必须具有指定数量的被认为“太多”的参数。在PMD的情况下，该默认数字为10。请注意，此触发PMD规则的默认最小阈值高于Steve McConnell建议的7个最大参数，并且大大高于Robert Martin建议的少于三个参数。

可通过PMD插件获得NetBeans PMD支持。还可以通过软件质量环境插件获得NetBeans PMD支持。我在以前的文章NetBeans 7和软件质量环境以及在NetBeans 7中配置SQE插件中对此进行了介绍。 QAPlug-PMD是用于IntelliJ IDEA的类似插件，而PMD Eclipse可用于Eclipse 。

Checkstyle

与PMD一样， Checkstyle 会检测并警告过多的方法和构造函数参数。 Checkstyle在其主页上定义为“一种开发工具，可帮助程序员编写符合编码标准的Java代码。” 特别是，Checkstyle为ParameterNumber “ check ”提供了描述，“检查方法或构造函数的参数数量。” 在Checkstyle的情况下，构造函数或方法的默认“最大参数允许数量”为7（与Steve McConnell的建议相同）。

Checkstyle可以使用Checkstyle Beans插件与NetBeans结合使用。与NetBeans PMD支持一样，也可以通过前面提到的Software Quality Environment获得NetBeans中的Checkstyle支持。 eclipse-cs插件支持将Checkstyle与Eclipse集成，而Checkstyle-IDEA是IntelliJ IDEA的类似插件。

CodePro Analytix

CodePro Analytix是Google Java开发人员工具的一部分，被描述为 “ Eclipse开发人员的首要Java软件测试工具，他们关心提高软件质量，降低开发成本和进度。” 它包括代码审核功能，其中一类规则是“ 程序复杂性” 。这些规则之一是“ 大量参数 ”规则。该规则的摘要是“方法不应包含太多参数”，其描述为：“此审核规则将查找具有超过指定数量参数的方法。超过此数目的方法可能太复杂。考虑将与它们相关的某些价值和行为移到一个单独的类中。”

还值得注意的是，CodePro Analytix还支持“平均参数数量”指标用于指标报告。该度量标准报告每个方法的平均参数数量，但不包括构造函数。

NetBeans Java代码指标提示

我已经提到了用于Checkstyle和PMD的NetBeans插件，但是我在NetBeans中最喜欢的功能之一是众多且高度可定制的内置NetBeans提示和检查。 NetBeans 7.4引入了一个全新的提示类别，称为“ Java代码度量 ”，这些新提示之一是“构造函数声明了太多参数”提示。此提示描述为：“使用太多参数的报表构造函数。构造函数通常比常规方法采用更多的参数，尤其是在初始化大对象时。大量参数表示设计不良。将来可能还会添加更多参数，因此应考虑使用诸如Builder之类的创建模式。” 在本系列的上一篇文章中，我介绍了构建器模式的应用，甚至讨论了如何使用NetBeans重构构建器。

另一个新添加的提示“ Method声明了太多参数”被描述为“ Reports方法使用了太多参数”。具有大量参数的方法表明设计不良。将来可能还会添加更多参数，因此应将这些参数分组到一个Command Object中，从而降低维护成本。另外，该方法可以重构为几种方法，每种方法都完成一部分任务，并且在输入时需要较少的参数。” 推荐的方法本质上与我在本系列文章的前面博客中提到的参数对象方法相同。

默认情况下，NetBeans 7.4的“ Java代码度量”类别中的所有提示均被禁用。在他的博客文章“ 我的代码到底有多混乱？ ”，“偶尔”的NetBeans博客Geertjan Wielenga演示了如何配置Java Code Metrics使其处于活动状态。

下一个屏幕快照演示了NetBeans 7.4中Java Code Metrics的使用。通过选择“源”，然后选择“检查...”（将打开NetBeans 7.4“检查”窗口）进行配置。

在“检查”窗口中选择“使用”标签和“配置”项目符号旁边的下拉菜单时，可以使用下一个屏幕快照中指示的选项。

出于演示目的，我选择“所有分析”，然后单击“检查”按钮。下一个屏幕快照演示了正在进行的检查/分析。

NetBeans Inspect机制“开箱即用”，发现一堆我的代码缺少Javadoc语句，但是没有用太多参数来标记构造函数和方法。为了解决这个问题，我需要遵循Geertjan博客文章中的步骤。为此，我可以单击Source | 检查并将“配置”选择为“默认”。

选择“默认”使我现在可以单击“管理...”按钮，然后单击该按钮将显示“配置”窗口。

单击“默认”标签会导致一个下拉菜单，从中可以选择“新建...”。

我可以将新配置命名为“ Java Code Metrics”。

单击“分析器”标签旁边的下拉菜单，可以选择“ NetBeans Java提示”，然后选择该选项可以按类别显示所有NetBeans Java提示。下一个屏幕快照显示了我可以选择要检查的代码度量。

下一个屏幕快照指示我可以选择“构造函数声明太多参数”作为复选框，而选择“方法声明太多参数”作为另一个复选框。

通过新的“ Java代码度量”检查，现在可以通过单击“检查”按钮轻松检查那些特殊问题。

按下“检查”以应用新创建的“ Java代码度量”检查，将在以下屏幕快照中显示结果。第一个图像显示了高级结果，随后的图像显示了通过单击高级结果而提供的更多详细信息。

使用我所介绍的所有静态分析工具，对于一个构造函数或方法，可以调整被认为“太多”的参数数量。借助NetBeans的Java Code Metrics支持，此配置确实非常容易。接下来的两个屏幕快照展示了分别在我们要检查的选项所在的同一窗口中为构造函数和方法设置了这些值的情况。每个选中的选项的扩展窗口包括检查类型的定义和用于选择适用参数数量的字段。

能够轻松更改被认为不可接受的参数数量（或至少值得指出以便可以应用“眼力测试”）是一件好事，因为对于不可接受的数量存在如此广泛的意见。

如最后一系列屏幕快照所示，NetBeans 7.4允许我们专门检查代码中“参数太多”的方法和构造函数。在撰写本文的这一部分时，我想起了NetBeans提供了重要的静态代码分析支持。

IntelliJ IDEA检查

IntelliJ IDEA提供了检查以找出具有过多参数的方法。 “ 参数过多的方法 ”检查描述为：“此检查报告参数过多的方法的所有实例。参数过多的方法表明必须进行重构。其签名是从库类继承的方法将被此检查忽略。” 此检查允许配置的方法参数数量过多。

其他静态分析工具

除了我已经集中讨论的工具以外，还有其他工具可以通过静态分析在Java方法或构造函数接受“参数过多”时进行标识和标记。其中包括Java Coding Standard Checker和Sonar 。所有这些识别“参数太多”的静态分析工具的存在证明了参数太多可能是维护和可读性的问题。

代码变更工具

到目前为止，本文中讨论的工具在分析代码以查找期望参数过多的现有方法和构造函数方面非常有用。一旦确定，就可以手动更改/重构这些构造函数和方法，以减少参数的数量，例如我在本系列过多参数系列的较早文章中概述的方法。幸运的是，有一些工具可以帮助进行这些重构和新的代码生成工作。现代Java IDE在重构和代码生成方面特别有用。

重构

构造器的应用程序是我处理构造器参数过多的最喜欢的方法之一。幸运的是，NetBeans能够依靠大量参数构造函数来自动重构代码以使用构建程序实现。我以前在“ Java方法中的参数太多，第3部分：构建器模式和NetBeans 7.2：将参数化构造函数重构为Builder”中发表了关于此方法的博客。 IntelliJ IDEA有一个类似的重构工具，称为Builder 。 Builder Pattern Eclipse插件可用于Eclipse。

代码生成

我最喜欢的处理太多参数的方法包括编写新的自定义类型和创建参数对象。现代Java IDE在这里非常有用，可以简化这些类和枚举的生成。通常只需几分钟即可生成具有适当的toString（）， hashCode（）和equals（Object）实现的完整类。很难说，鉴于使用现代Java IDE及其代码生成功能编写自定义类型类和参数对象（命令）类太容易了，因此编写自定义类型类和参数对象（命令）类太“昂贵”。

结论

这篇文章的重点是Java开发人员可以用来在Java代码中识别方法和/或构造函数期望太多参数的位置的工具，以及可以轻松地修复这些构造函数和方法以接受更合理数量的Java工具的可用工具。参数。有几种静态分析工具和IDE支持对期望过多参数的构造函数和方法的快速识别，而现代Java IDE使重构和代码生成变得轻松快捷。可用于识别“太多参数”问题的大量工具提醒我们，这实际上是一个值得解决的问题。

参考： Java方法中的参数太多，第8部分：来自JCG合作伙伴 Dustin Marx的工具，来自Inspired by Actual Events博客。