Java 中的私有輔助方法與公共靜態實用程序方法

Question

我有一個正在變長的 Java 類。 當我通過代碼質量工具運行它時，我被標記為類中的行數。

這是一個較低層的類，由帶有Spring 的@Autowired上層使用。 該類有許多非靜態的私有實例方法。 它們不使用任何實例字段，只處理方法參數。

我可以在某個單獨的實用程序類中安全地將這些方法作為public static方法移動嗎？ 有什么缺點？

Answer 1

這里的“錯誤”心態。

你沒有重做你的課程，因為工具抱怨這個或那個。

您希望提高源代碼的質量 ; 這些工具可以幫助識別“值得思考的主題”。 你把他們的反饋作為暗示 ; 不是“秩序”。

因此，您不必擔心類中的“代碼行”。 相反，您擔心這門課的責任 。 含義：行號計數本身不是問題 - 但違反單一責任原則的是。

因此：你退后一步，看看你班上到底在做什么。 當它顯然不止一件事時，你將這些方面提取到其他類中！

含義：如果您確實發現所有這些代碼都“屬於”該類的責任; 然后把它留在那里。 不要開始將內部實現細節放入不相關的幫助程序類中; 只是因為某些工具會警告你行數。

另一方面，將私有方法轉換為靜態/包保護的東西將允許您對這些方法進行單元測試。 這可能是一個優勢。 但正如所說：只要我們談論實施細節 ，他們應該保持私密; 並且他們不應該進行單元測試。

長話代碼：了解並理解“干凈代碼”的含義; 並嘗試遵循那里概述的想法。

Answer 2

方法的划分應該是目的/應用/邏輯（你的名字），而不是技術屬性。

長源代碼可以分成幾個小的類，每個類都有自己獨立的目的/責任。

Answer 3

我經常使用包含靜態方法的Utility類，並且發現它非常方便。 如果這些方法僅供單個類使用，則可以將Utility類作為靜態私有類放在原始類中。 但是我發現在很多情況下，一些靜態實用程序方法可以被幾個類使用，所以在這種情況下我創建一個單獨的實用程序類，其中包含一組可以由幾個類使用的靜態方法。

另外，我非常贊同GhostCat在一般思維方面的答案。 至於班級的規模 - 這可能是一個問題，但通常我不擔心這么多。 我真正尋找的是你的方法的大小。 我喜歡簡短和自我解釋的方法，從名稱和參數名稱和順序以及邏輯開始。 如果有大塊內部邏輯 - 將其提取到單獨的方法中。 這使得代碼更易於閱讀和維護。

Answer 4

代碼質量無法通過行數來衡量。 如果您發現類文件日益增長，請確保您的課程遵循單一責任原則。

當您的課程不遵循原則時，將它們分成單獨的類並將類分成一個包。

否則，您可以將基類作為抽象類 ，並將您的util方法設為abstract 。 有一個子類，它擴展了基類，為基類中的抽象方法提供了實現。

當你可以將你的方法設置為靜態時，這是一個很好的答案

正如@Zack Jannsen所說，

當您知道某些事物不會在實例中發生變化時，“靜態”通常很有價值。 如果是這種情況，我會真正考慮“單一責任原則”，這意味着一個班級應該有一個責任，因此只有一個改變的理由。 我覺得應該考慮將“ConvertMpgToKpl（雙mpg）”函數和類似的方法移動到他們自己的類中。 汽車對象的目的是允許汽車的實例化，而不是在它們之間進行比較。 那些應該是班級的外部。

雖然static允許您在沒有創建對象的情況下訪問該方法，但在嘗試將該方法設置為靜態時，請始終記住以下內容

• 該方法根據輸入參數生成一致的結果
• 你總是需要那個方法在內存中（即;你經常需要這個方法） - 訪問一個巨大的方法可能會更好，這個方法在對象創建的幫助下只能訪問很少次，而不是通過static訪問它
• 經常使用的實用方法可以是static

Answer 5

在我看來，使用正在執行一些“魔術”的私有方法有點危險，因為您無法真正對其進行單元測試。 是的，您當然可以對調用該私有方法的公共方法進行單元測試，但請考慮一下您將擁有的漸近復雜性。 通常我更喜歡為這些方法使用實用程序類並編寫一些大量的單元測試。