如果您很不幸不能在一個項目中與我一起工作，那么您將遭受所有軟件包依賴項必須無循環的規則的困擾。 我不僅需要這樣做 ，而且還將創建一個單元測試，以確保使用Degraph進行測試。 這就是我認為無周期封裝結構對項目有益的原因。

有用的抽象 ：如果您在實現內容時沒有過多考慮依賴項，則幾乎可以肯定會得到循環依賴項。 為了打破這些周期，您通常必須以接口的形式引入新的抽象。 與以前的直接依賴關系相比，這些接口通常可以為應用程序中的操作創建更清晰的抽象，例如考慮兩個相互依賴的包Something和Other 。 正如描述的那樣，沒有辦法說出它們為什么相互依賴。 但是為了打破依賴關系之一，您可能決定引入一個接口。 該接口的名稱可能包含有關兩者之間關系的有價值的附加信息。 想象一下，該接口最終被命名為SomethingDeletionListener ，位于Somehting中并在Other中實現。 這已經告訴您有關兩個軟件包之間關系的信息，不是嗎？

干凈的正交包結構 ：每當您在樹狀結構中組織某些東西時，您可能都希望在該樹中形成正交結構。 這意味著在分支的所有子分支上都是單一分類的元素。 一個很好的例子是Customer ， Order ， Wishlist ，另一個很好的例子是UserInterface ， Persistence ， Domain 。 這些結構清楚地表明了類所屬的位置。 如果將這兩種方法混合使用，最終會得到諸如Customer ， Order ， Persistence之類的東西。 在這樣的結構中，完全不清楚用于持久性客戶的類在哪里。 結果是一團糟，通常會導致依賴關系中的循環，因為諸如客戶應該依賴于持久性之類的問題或其他方法甚至都沒有道理。

啟用重用 ：是否曾經嘗試過重用一個包，甚至是一個不在乎依賴項的項目中的單個類？ 我試過了。 在十分之九的案例中，我有兩種選擇：要么選擇整個項目（實際上不是一個選擇），要么對類進行一些繁重的重構，然后再進行編譯，而無需在項目中包含所有其他內容。 另一方面，在項目中，程序包的依賴關系形成了一個很好的有向無環圖，這很清楚該類需要做什么。 人們對重用感興趣的東西通?？拷鼒D的葉子，可以單獨提取，也可以很少依賴。

允許部分重寫 ：有時一個曾經被認為很棒的想法變成了一個非常糟糕的想法。 有時情況很糟，您想重做。 非循環依賴性限制了受更改影響的代碼量。 由于具有周期性依賴性，整個應用程序通常至少有受到影響的危險。

獨立部署 ：另一方面，有時想法實際上是很棒的。 也許如此之大以至于它們被大量使用，以至于您需要對其進行擴展并單獨部署在三臺其他服務器上，以應對沉重的負載。 祝您好運，將您的應用程序分為兩個或兩個以上的部分，當程序包之間纏結在一起時，可以將它們分開部署。 使用無循環結構，可以切割的地方應該很明顯。

翻譯自: https://www.javacodegeeks.com/2014/11/five-reasons-why-you-should-keep-your-package-dependencies-cycle-free.html

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的为什么要保持软件包依赖项自由循环的五个原因的全部內容，希望文章能夠幫你解決所遇到的問題。

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