每個包有多少班？每班的方法？每種方法的線？

Question

我必須對一些巨大的Java項目給出一般性的說明，但我很少見，我想知道是否有任何指導方針來確定：

• 每個包的類數可以被認為是正確的，低的還是高的（這個項目每個包有3.89個類，這對我來說似乎有點小），
• 每班的方法數量？ （這個項目每班有6.54個方法......
• 每種方法的行數？ （這個項目每個方法大約有7行（對我來說似乎很好，可能有點低））

我應該注意到這個問題只涉及體積測量。 我從質量工具（checkstyle，jdepend，cpd，pmd，ncss）獲得了大量報告，這些報告讓我對代碼冗余，類使用，錯誤等有了更多的了解。

Answer 1

史蒂夫麥康奈爾在他的書“代碼完成”中推薦每個類約7種方法，然后在一個方法中不再有行可以在不滾動的情況下在單個屏幕中查看。

我不確定每個包的類。

我強烈建議您閱讀Code Complete以獲取有關此類主題的更多信息。

Answer 2

我認為像這樣的統計數據是非常無用的，知道每個方法的行數如何表明它對項目是否有用; 我認為你應該更多地看待：

1. 你的包裹是否包含類似的課程？
2. 您的課程是否自己作為一個實體工作？
3. 類中的方法是否正確有效地運行？

當然，除了內存使用之外，方法是否很大並不重要？ 在非常長時間的方法中尋找的另一件事是堆棧跟蹤是否比將該功能添加到父方法更大。 我會謹慎地根據代碼行來衡量項目的成功。

Answer 3

最近發布“清潔代碼”一書的羅伯特·C·馬丁表示，每種方法的線數應盡可能絕對最小。 在1-7行之間是一個很好的經驗法則。

在傑夫·貝（Jeff Bay）的文章“對象健美操”（Object Calisthenics）中，“思想工具集”（ThoughtWorks Anthology）一書中也有一個很好的觀點。 他建議9個非常嚴格的約束條件，從長遠來看，這將使你成為一個更好的OO開發者。 在這里閱讀更多相關信息。

要回答您的具體問題，這些是您特別要求的限制： - 每個包不超過10個類 - 每個類最多50行

這些約束對於你所有的真實項目可能並不理想，但在一個小的（業余愛好？）項目中使用它們會迫使你進入更好的實踐。

Answer 4

不幸的是，軟件中沒有絕對的（客觀的）質量概念。 因此，這些沒有“正確”的價值。 但是，這里有兩個（個人）的觀點：

3.89班/包非常低。 這意味着你將在一個復雜的包樹叢中戰斗。

每種方法7行：確實聽起來不錯。 但是，如果這些數字是由於有意減少方法的行數而得出的，那么你可能最終會將一個邏輯任務分散到幾個私有方法中，這將使得理解該類更加困難（在某些情況下）。 實際上，在CodeComplete-2中，作者引用了一項研究，該研究發現方法長度遠不如其圈復雜度及其嵌套水平重要。

Answer 5

一個有用的設計指南說每個班級應該只做一件事並做得好。 這不會為每個類提供固定數量的方法，但它會限制數量並使類更易於理解和維護。

對於方法，您可以采用類似的視圖，並針對盡可能小但不小的方法。 可以這樣想：如果你可以將方法分成兩個或多個不同的部分，那么它顯然不會像它那樣小。 小方法很容易理解，通過拆分這樣的代碼，您可以在高級方法中獲得更好的概述，並將細節推送到低級方法。

Answer 6

（注意：tl; dr可以在最底部獲得我的真實意見）

我不會引用任何大名稱並說這是正確的答案，因為它總是非常依賴於你如何做所有這些事情。 例如方法的數量：如果你正在做對於具有約40-50按鈕現代高清液晶電視的遙控器控制軟件，你怎么能打破下來到類連貫 ，所以你只喜歡有，比如說，7種方法每節課？

我個人喜歡將一個訪問器級別的所有方法保存在一個類中，這意味着一些實用程序類可能最終會有數百個方法，但在我看來，像StringUtil.escapeXMLspecialCharacters(someString)更容易做一些比StringUtil.XML.escapeSpecialCharacters(someString)或XMLUtil.escapeSpecialCharacters(someString) 。 雖然這些都是看似不錯的解決方案，但第一個解決方案是蓬勃發展的（至少在我看來，就是這樣！）因為訪問該方法很簡單，也很簡單：你不必考慮你正在處理的字符串是否包含XML或XHTML或JSON或其他什么，您只需從一般方法組中選擇一種方法，就是這樣。

保持以前的電視遙控器類比，讓我們假設您將它們分成各種類別。 如果我們允許自己平均每個類有7個這樣的方法，並設法將遙控器上的按鈕分組到感覺組，如MenuButtons ， AdjustmentButtons和'NumberSelectorButtons'，我們最終會有8個左右的類。 這實際上並不是一件壞事，但它會輕易引起混淆，特別是如果他們沒有非常謹慎地分配給敏感的團體。 想象一下你的TVRemotes'R'Us Inc.辦公室周圍的咆哮：“誰說電源開/關按鈕是一個控制按鈕？” “誰是將音量+/-放到菜單按鈕上的小丑？PRE / CH （在當前和上一個頻道和/或圖像源之間切換的按鈕）按鈕不是數字按鈕！” “指南按鈕根據上下文打開電視指南和導航菜單，我們將用它做什么！？”

因此，您可以從這個示例中看到，使用一些任意數字來限制自己可能會引入一些不必要的復雜性並打破應用程序的邏輯流程。

在我投入最后兩分之前，關於每個方法的行數有一點：將代碼視為塊。 每個循環都是一個塊，每個條件都是一個塊，依此類推。 單個代碼單元所需的這些塊的最小數量是多少？ 這應該是你的限制因素，而不是渴望擁有“七處無處不在”。 從包中的類數，類中的方法和方法中的代碼行。

這是TL; DR ：

所以，我的真實意見實際上是這樣的：包中的類數量應該相當低。 我最近開始做以下事情，但我不確定我是否會跟上它：

• 包foo包含用於實現的接口和其他公共類。
• 包foo.bar包含功能bar的所述接口的實現
• 包foo.baz包含函數baz的所述接口的實現

這通常意味着我的整個結構具有連貫的（並且很可能是低的）類的數量，並且通過閱讀頂級類接口（及其注釋），我也應該能夠理解其他包。

每個類的方法：如上所述，所有需要的方法。 如果你的班級不能沒有170種方法，那就讓它擁有它們。 重構是一種美德，而不是一直可以應用的東西。

每種方法的線數：盡可能低，我通常最終每個方法有10到25行，而25對我來說有點高，所以我認為10是一個很好的平衡點。