我希望我們都同意，方法和類應(yīng)該很小，并且只有很少的依賴關(guān)系。 這種觀點被廣泛接受，而對“小”的解釋則各不相同。 關(guān)于這一點有很多文獻(xiàn)。 但是包裹呢？

有些人將包視為名稱空間。 因此，包只是允許您為類重用名稱的東西！

幾年前，我對方法進行了思考：只是用于可重用代碼的容器。

今天，我不同意這兩種說法。 方法是命名事物，將事物與其余事物分開的非常重要的工具，即使僅被調(diào)用一次也是如此。

同樣，即使我們忽略名稱問題，軟件包也起著重要的作用。 軟件包將某些功能捆綁在一起。 他們?yōu)樵摴δ苊?#xff0c;應(yīng)該對其進行封裝，以便我們重新使用它。 就像方法一樣，程序包應(yīng)具有單一目的。 它可能比方法的目的“更大”，但是它仍然應(yīng)該只做與該目的直接相關(guān)的事情。

不幸的是，在許多項目中，這不能很好地解決。

這是一個挑戰(zhàn)。 從當(dāng)前項目中隨機選擇一個軟件包。 對于此軟件包，請回答以下問題

• 該軟件包的目的是什么？ 請使用一個簡單的句子。 這句話與包裹名稱相符嗎？
• 遍歷該程序包的類，它們是否都共同努力以達(dá)到該類的目的？ 還是那里偶然偶然地出現(xiàn)了課程？
• 遍歷系統(tǒng)的所有其他類。 他們都不關(guān)心您包裹的單一用途嗎？ 還是有一些類浮在其他地方，而這些地方確實應(yīng)該放在您正在查看的包中？
• 如果您在下一個項目中的同事需要基本相同的軟件包，那么從您的代碼庫中提取該軟件包并將其構(gòu)建為獨立的jar將有多困難？

以我的經(jīng)驗，上述問題的答案很可能令人沮喪。 他們肯定參與了我合作過的大多數(shù)項目。

即使該項目中的類和方法相當(dāng)合理。

這是為什么？

我認(rèn)為原因是程序包的問題不如方法或類明顯。 如果某個方法跨越整個監(jiān)視器，則您將始終看到使用該方法的所有時間。 而且由于該方法很長，因此可能需要做很多工作。 類相同。 但是跟套餐不同。 我花了整整一整天的時間在編碼中，而不看包裝里面的東西。 我使用快捷方式和基于名稱的搜索打開類，而無需查看包內(nèi)部。

因此，您不會注意到與完全不同的問題相關(guān)的類放在一個包中。 您不會注意到包中的類數(shù)超過了任何合理的閾值。

如果涉及到最后一個問題，關(guān)于依賴關(guān)系的問題將變得非常丑陋。 軟件包還依賴其他哪些軟件包？ 哪個類包含該依賴項？ 對于此類問題的工具支持非常有限。 而且問題只會在項目后期才問到，也許是當(dāng)產(chǎn)生了一個姊妹項目時，該項目應(yīng)該重用一些代碼庫，因此應(yīng)該在一個通用的基礎(chǔ)項目中移動。

由于我去過幾次，所以建議在項目開始時使用JDepend或Dependency Finder進行一些測試：

• 包之間沒有循環(huán)依賴
• 每個包的最大類數(shù)
• 固定的命名架構(gòu)，例如<domain>。<project>。<module>。<layer>。<package-of-package-name>
• 模塊之間的依賴關(guān)系的固定方向（模塊是垂直切片，通常基于某些域概念）
• 層之間的依賴關(guān)系的固定方向（gui，表示，域，持久性是典型示例）

但請注意：這些測試往往很難保持滿意。 但是，如果您付出額外的努力來保持程序包的清潔，則會對您的應(yīng)用程序結(jié)構(gòu)產(chǎn)生重大的積極影響。

參考： 關(guān)于 Schauderhaft博客上JCG合作伙伴 Jens Schauder的軟件包 。

翻譯自: https://www.javacodegeeks.com/2012/05/about-java-packages.html

總結(jié)

以上是生活随笔為你收集整理的关于Java包的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。