山东房和城乡建设厅网站,杭seo网站建设排名,如何选择做网站的公司,中秋节网页设计实训报告java命令行参数工具在我的系列文章的前七篇文章中#xff0c;有关处理Java方法中期望的参数过多的内容集中在减少方法或构造函数期望的参数数量的替代方法上。 在本系列的第八篇文章中#xff0c;我将介绍一些工具#xff0c;这些工具可帮助您确定可能存在过多参数的情况有关处理Java方法中期望的参数过多的内容集中在减少方法或构造函数期望的参数数量的替代方法上。 在本系列的第八篇文章中我将介绍一些工具这些工具可帮助您确定可能存在过多参数的情况以及有助于在出现这种情况时进行处理的工具。 对于方法或构造函数中过多的参数实际上并没有硬性规定 。 在许多方面这都是一个问题在一定程度上取决于这些参数是什么它们是否使用自定义类型而不是原始类型和重复类型以及是否存在可能需要传递null的可选参数。 罗伯特·马丁 Robert Martin 在《 清洁代码》中写道 第40页 函数的理想参数个数为零尼拉度。 接下来是一个单声道紧接着是两个双声道。 在可能的情况下应避免使用三个参数三重性。 超过三个多义词需要非常特殊的理由-因此无论如何都不应使用。 在《代码完成》中 史蒂夫·麦康奈尔 Steve McConnell写道开发人员应“将例程参数的数量限制为七个左右”因为“七个是让人理解的神奇数字。” 我不认为有任何设定的最大参数数目但是七个参数似乎似乎很少超过“经验法则”而且我通常更喜欢较小的数目例如Martin建议的参数少于三个。 “眼睛测试” 体育谈话和体育写作中有一个共同的表达即某些球员或球队“没有通过视力测验”。 我对这种表达的理解是这意味着尽管有任何积极的统计数据可能与该球员或团队相关联但观看球员或团队的比赛会让人们相信他们并不如统计数据所示。 换句话说以一种难以描述的方式观看者感觉到团队或球员并不像他们的统计数据所暗示的那样熟练。 在许多方面软件开发都有其自己的“眼力测试”可以告诉我们某些事情何时比“规则”所暗示的好或坏。 尽管如此我们仍然拥有关于“规则”或一般性指导原则以了解如何构成良好的软件习惯就像体育比赛中有统计数据试图客观地对比球队和球员一样。 例如在软件中我们可能会说“参数较少通常比更多参数要好。” Tooling的最大局限性在于它无法为我们执行“眼力测试”但可以帮助我们确定潜在的改进领域。 换句话说工具可以帮助报告游戏或比赛的“统计数据”但是我们必须对工具所报告的内容做出自己的判断“眼力测试”。 静态分析工具 静态分析工具可用于自动识别可能期望太多参数的方法或构造函数。 一旦确定了可能带有太多参数的方法和构造函数开发人员便可以对其进行“眼力测试”以确定是否应采取纠正措施。 PMD PMD 带有幽默的口号“ Do nt 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和equalsObject实现的完整类。 很难说鉴于使用现代Java IDE及其代码生成功能编写自定义类型类和参数对象命令类太容易了因此编写自定义类型类和参数对象命令类太“昂贵”。 结论 这篇文章的重点是Java开发人员可以用来在Java代码中识别方法和/或构造函数期望太多参数的位置的工具以及可以轻松地修复这些构造函数和方法以接受更合理数量的Java工具的可用工具。参数。 有几种静态分析工具和IDE支持对期望过多参数的构造函数和方法的快速识别而现代Java IDE使重构和代码生成变得轻松快捷。 可用于识别“太多参数”问题的大量工具提醒我们这实际上是一个值得解决的问题。 参考 Java方法中的参数太多第8部分来自JCG合作伙伴 Dustin Marx的工具来自Inspired by Actual Events博客。 翻译自: https://www.javacodegeeks.com/2013/11/too-many-parameters-in-java-methods-part-8-tooling.htmljava命令行参数工具
