軟件開發領域的很大一部分是使系統的復雜性盡可能地低。 但是復雜性到底是什么？ 雖然確切的語義有很大不同，但取決于您詢問的人，大多數人可能都認為這與系統中部件的數量及其交互有很大關系。

考慮太空中的大理石，即行星，月亮或恒星。 沒有任何交互，這就像系統可能會變得無聊。 什么都沒發生。 如果大理石移動，它會以完全相同的方式移動。 老實說，甚至沒有辦法確定它是否在移動。 笨蛋。

在系統中添加第二塊大理石，讓它們彼此吸引，就像地球和月亮一樣。 現在，該系統更加有趣。 如果它們不太快，則這兩個對象會彼此繞圈。 有點有趣。

現在添加第三個對象。 在一般情況下，事情變得如此有趣，以至于我們甚至無法預測會發生什么。 整個系統不僅變得復雜，而且變得混亂。 您現在有一個三體問題 。在一般情況下，此問題無法解決，即我們無法預測系統會發生什么。 但是有一些特殊情況。 尤其是其中兩個對象彼此非常接近的情況（例如地球和月亮），而第三個對象相距太遠，以至于兩個第一個對象的行為就像一個對象。 在這種情況下，您可以用兩個粒子系統來近似該系統。

但是，這與Java有什么關系？ 這聽起來更像物理學。

我認為軟件開發在某些方面是相似的。 完整的應用程序是從整體上變得復雜的方式。 為了克服這種復雜性，我們將系統分為可以自己理解的部分（類），并隱藏了它們的內部復雜性，這樣，當我們查看較大的圖片時，不必擔心代碼中的每個代碼行類，但僅將類作為一個實體。 實際上，這與物理學家對系統所做的非常相似。

但是，讓我們看一下事物的規模。 軟件的基本構建塊是代碼行。 為了控制復雜性，我們將在方法中一起工作的代碼行捆綁在一起。 單個方法中有多少行代碼會有所不同，但大約為10行代碼。

接下來，將方法收集到類中。 一個類中有多少種方法？ 通常按10種方法排序！

然后？ 我們將100-10000個班級捆綁在一個罐中！ 我希望我不是唯一認為某事不對勁的人。

我不確定從Jigsaw項目中會得到什么，但是目前Java僅提供軟件包來捆綁類。 包并不是一個強大的抽象，但是它是我們唯一的抽象，因此我們最好使用它。

大多數團隊確實使用軟件包，但不是以非常結構化但臨時的方式使用軟件包。 結果類似于試圖將月亮和太陽視為系統的一部分，而將地球視為另一部分。 結果可能有效，但可能與托勒密的行星模型一樣直觀。 取而代之的是，根據標準確定如何區分包裝。 我個人稱它們為切片，是受Oliver Gierke的一篇文章的啟發。 按重要性順序排列的可能切片為：

• 該類最終應位于的可部署jar文件
• 類所屬的用例/功能/業務模型的一部分
• 類所屬的技術層

結果生成的軟件包將如下所示：<domain>。<deployable>。<domain part>。<layer>

決定去哪兒上課應該很容易。 并且即使您不使用技術層分隔，它也應將包裝保持在合理的尺寸。

但是，您從中得到什么呢？ 找到類比較容易，但是僅此而已。 您還需要一個規則來使它真正值得： 不得有循環依賴項！

這意味著，如果包A中的類引用了包B中的類，則B中的任何類都不能引用A。如果引用是通過多個其他包間接引用的，則這也適用。 但這還不夠。 切片也應該是無周期的，因此，如果域部分X引用了其他域部分Y，則反向依賴性一定不存在！

實際上，這將對您的程序包和依賴項結構設置一些相當嚴格的規則。 這樣做的好處是，它變得非常靈活。

沒有這樣的結構，將您的項目分成多個部分可能會很困難。 是否曾經嘗試過在另一個應用程序中重用應用程序的一部分，只是為了意識到您必須包含大部分應用程序才能進行編譯？ 是否曾經嘗試將應用程序的不同部分部署到不同的服務器，只是為了意識到自己做不到？ 在使用上述方法之前，這肯定發生在我身上。 但是，通過這種更嚴格的結構，您可能想重用的部分將幾乎完全依賴于依賴鏈的末端，因此您可以將它們打包并捆綁在自己的jar中，或者只是將代碼復制到不同的容器中項目并在很短的時間內進行編譯。

同樣，在嘗試保持軟件包和分片周期自由的同時，您將不得不認真思考，每個涉及的軟件包實際上都是關于什么的。 在許多情況下，這些可以極大地改善我的代碼庫。

因此，剩下一個問題：依賴關系很難看到。 沒有工具，很難保持代碼庫的自由。 當然，有很多工具可以檢查周期，但是清理這些周期很困難，而且大多數工具提供這些周期的方式也無濟于事。 我認為一個需求是兩件事：

一個簡單的測試，可以與所有其他測試一起運行，并且在創建依賴項圈時失敗。

可視化類之間所有依賴關系的工具，同時顯示每個類所屬的切片。

驚喜！ 我可以推薦一個很棒的工具： Degraph ！ （我是作者，所以我可能會有偏見）

您可以像這樣在JUnit中編寫測試：

assertThat( classpath().including("de.schauderhaft.**") .printTo("degraphTestResult.graphml") .withSlicing("module", "de.schauderhaft.(*).*.**") .withSlicing("layer", "de.schauderhaft.*.(*).**"), is(violationFree()) );

該測試將分析類路徑中以de.schauderhaft開頭的所有內容。 它將以兩種方式對類進行切片：通過獲取包名稱的第三部分和通過獲取包名稱的第四部分。 因此，類名de.schauderhaft.customer.persistence.HibernateCustomerRepository最終出現在模塊客戶和層持久性中。 并且它將確保模塊，層和包是無周期的。

并且，如果找到依賴項圓，它將創建一個graphml文件，您可以使用免費的圖形編輯器yed打開該文件 。 通過一點布局，您將得到如下所示的結果，其中導致循環依賴關系的依賴關系被標記為紅色。

同樣，有關如何實現良好的可用布局的更多詳細信息，我必須參考Degraph的文檔 。

另請注意，圖表主要以綠色為主，并帶有少許紅色，非常適合本季節！

翻譯自: https://www.javacodegeeks.com/2014/12/managing-package-dependencies-with-degraph.html

總結

以上是生活随笔為你收集整理的使用Degraph管理软件包依赖关系的全部內容，希望文章能夠幫你解決所遇到的問題。

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