我記得大約15年前開始學習Java的時候。 我讀了很多有關“包裝”和“命名空間”的東西，但我完全不了解。 可悲的是：雖然包裝的某些方面幾乎為業內每個人所了解，但其他方面卻并非如此。 因此，讓我們看一下哪些軟件包最適合。

命名空間：

通過為您的所有程序包加上您所控制的域的前綴，可以確保您的類名是唯一的。 這對于數量驚人的開源項目的成功至關重要。 每個項目都可以（并且可能在某個階段做一個）定義一個“ Filter”類，而不會干擾該類的所有其他同名類（可憐的開發人員除了從網絡上復制了一些沒有導入語句的代碼外，現在有了以確定實際引用了哪個Filter類）。 這是一個很好的理解，而且我還沒有看到根軟件包的任何相關用法。

組織：

我兒子有一大盒樂高積木。 可能有成千上萬個。 當他尋找簡單的2×4磚塊時，這不是問題。 但是，當他正在搜索僅在集合中存在4次甚至只有一次的特殊磚塊時？ 可能需要很長時間才能找到它。 將其與藥劑師柜子比較。 數百種藥物，通常只需幾秒鐘即可找到合適的藥物。 而且他們甚至都沒有使用Google！ 它們只是每種藥物所屬的嚴格訂購原則，包括一條規則，即如何確定新藥的正確框。 由于涉及的每個人都知道該原理，因此很容易確定要在其中找到毒品的正確盒子。 當在項目早期建立時，這種排序原則將非常有用。
在定義這樣的原則時，一個標準在大多數時間是不夠的。 但是，如果您使用更多的規則，則使規則正交，以確保它們不會干擾。 這意味著沒有規則說：“所有數據庫訪問代碼都必須放在軟件包x中”，而另一條規則規定“與客戶相關的所有代碼都必須放入軟件包y中”。 否則，您將不知道將CustomerDAO放在哪里。 而是在包樹的不同深度上應用正交規則。 我的默認包結構如下所示：

<organisational-prefix>.<application>.<deployment-unit>.<module>.<layer>.<optional further substructure if needed>

這將導致軟件包名稱，例如com.mycompany.theCoolApp.server.user.persistence或com.mycompany.theCoolApp.client.shoppingCart.presentation 。

如果您查看這樣的包結構，則很明顯新類屬于什么地方，或者類似的東西已經存在的地方。 如果避免使用諸如util或misc類的名稱，它們可能會或多或少隱藏所有內容，則效果會更好。 您也可以查看這些軟件包，并立即了解有關體系結構的知識。 一旦您看到一個名為client ， webserver和batchserver的軟件包級別，您就會在腦海中形成一個模型，說明應用程序的結構以及名稱的選擇是否正確。 由于在每個module中都應用了相同的layers規則，因此您也可以在較低的軟件包中找到有關應用程序結構的更多信息。

之間的module傳達應用程序要處理的領域的類型。 很自然，重要的概念會得到自己的包裝，從而使每個檢查代碼的人都可以聲明：這是此應用程序中的重要概念。

我還喜歡添加規則“A包必須包含a - b類，但不得包含c以上”與A，B和C的適當的值。 隨著應用程序的增長，這將迫使創建新的程序包，從而使每個程序包保持可管理的大小。

當然，在較小的應用程序中，結構可能會縮小。 例如，如果只有一個部署單元，則無需為該分類使用單獨的程序包級別。

包的最后一種用法是最被忽略的： 中間建模塊 ：Joe Average Developer主要關注類和方法以及單行代碼，同時嘗試在該級別上提出適合應用程序需求的代碼結構。 通常，有些架構師會弄清楚如何部署應用程序，從而確定必要的部署單元（請考慮單獨的jar）。 如果您看一下這些工件的規模，可能會發現一些有趣的東西：

• 1種方法由大約10行代碼組成。
• 1類包括大約10種方法。
• 1罐子大約包含100 – 1000類。

如果沒有人照顧軟件包，則至少會缺少一種結構，經常會缺少兩層結構！ 可以并且應該用包裝來填補這個空白。 這不僅意味著包裝應存在且尺寸合理，還意味著它們應遵循通用的設計準則。 特別是“ 單一責任原則”和對依賴項的正確處理：

單一責任原則：

利用上面提出的命名方案，完成了許多兌現SRP的工作。 如果軟件包的內容符合其名稱說明，那么在此方面一切都很好。

依賴性管理：

是更強悍的野獸。 Java當前沒有提供適當的系統來控制軟件包之間的依賴關系，尤其是超級軟件包，即包含多個其他軟件包的軟件包。 有OSGI ，但是我發現使用它很麻煩 ，特別是因為我不需要所有的動態加載內容，但是會遭受類加載器問題的困擾。 也有拼圖，但還不存在。 因此，我更喜歡使用本地測試來定義和驗證所使用的應用程序的程序包結構。 我選擇的工具是JDepend 。 它提供了程序包之間的依賴關系列表，您可以使用它們將它們與定義的規則進行比較。 有人創建了從程序包A到程序包B的依賴關系，該依賴關系不應該存在？ 動臂，測試變成紅色。
那么對包依賴項有用的規則是什么？ 第一：無周期。 不在包級別上，也不在layer級別上或module級別上，如上所述。 第二：模塊和層具有嚴格的順序，在順序上它們可以相互依賴，其他所有內容均被禁止。

這些規則極大地限制了開發人員的自由度。 但是以我的經驗，它消除了違反“單一責任原則”的情況，該原則經常以循環依賴的形式出現。 例如，如果您有一個“訂單”模塊和一個“客戶”模塊，則感覺這兩個需要彼此了解。 如果您有訂單，則想知道該訂單所屬的客戶。 如果您有客戶，則必須能夠告訴她所下的訂單。 對？ 應該是。 但是，您是否需要兩側都有完整的對象和功能？ 可能不是。 例如，通過提供一個接口程序包，其中僅包含訂購模塊所需的客戶功能的最核心部分，以及一個單獨的完整的具有參考訂單的客戶模塊， 可以打破這些依賴關系并在您的需求中實現更強的關注分離包裝結構。

當您嘗試開發應用程序時，這反過來會有所幫助。 今天的軟件包有一天可能會成長為一個部署單元，如果您在部署單元之間存在循環依賴關系，則會遇到一些嚴重的問題。 也許您的團隊成長為多個團隊。 有了如上所述的干凈的程序包結構，當團隊必須坐在一起討論由多個團隊使用的程序包的更改時，您將有明顯的界限可以拆分，并且還有明顯的標準。

參考：來自Schauderhaft博客的JCG合作伙伴 Jens Schauder 的軟件包重要性 。

翻譯自: https://www.javacodegeeks.com/2013/01/the-importance-of-packages-3.html