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博客。

翻譯自: https://www.javacodegeeks.com/2013/11/too-many-parameters-in-java-methods-part-8-tooling.html

java命令行參數工具

總結

以上是生活随笔為你收集整理的java命令行参数工具_Java方法中的参数太多，第8部分：工具的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。