structure101

穩定應用程序的一個關鍵是結構良好的代碼庫。 我們知道我們應該建立盡可能多的黑匣子，因為一旦完成一個黑匣子，我們就不必再考慮其內部了。 您只需要使用您或其他團隊成員通過明確定義的界面編寫的代碼即可。 這使您可以專注于要添加的下一個功能。

當我們想到黑匣子時，我們通常會想到類或整個jar包。 當然，課程應該是黑匣子，對此不做任何討論。 jar包也是如此。 但是在類和jar包之間有另一層結構，通常不能直接將其視為黑盒：包。

一攬子計劃通常是二等公民，對其相互關系的分析不夠深入。 但是有一個很好的工具可以進行這種分析： Structure101 。 通常，它可以通過組織良好的圖來幫助您監視和驗證項目的依賴關系結構和復雜性。

因此，讓我們從一個示例項目開始。 為此，我采取了自己的項目之一： japicmp是一種工具，用于根據更改的方法和類來計算兩個jar存檔的API之間的差異。 structure101有一個很棒的組合視圖，它向您顯示了項目包之間的依賴關系。 當前japicmp的外觀如下：

顯然，我們可以看到例如cli軟件包，它負責命令行解析，它使用異常以及config軟件包，并且由main（）方法所在的主軟件包本身使用。 使用cli軟件包，一切似乎都可以。 但是，三個軟件包cmp，util和model呢？ 類和方法（即業務邏輯）之間的差異計算位于程序包cmp中。 因此，它應該使用模型以及util包。 但是，這兩個軟件包不應具有任何向后依賴性。 此問題也顯示在矩陣視圖中：

當我們仔細查看這三個程序包之間的糾纏時，我們發現util程序包中使用了cmp程序包中的類AccessModifier：

除此之外，該類還用于模型中。 這清楚地表明，該類應該像在cmp包中那樣留在模型包中。 這似乎是有道理的，因為類或方法的訪問修飾符是jar存檔模型的一部分，并且不屬于業務邏輯。 如果將此類移至模型包，則會得到以下結果：

看起來好多了。 包裝結構內沒有任何纏結。 精美的布局還清楚地表明，整個應用程序都取決于模型，因為程序包位于圖的底部。 從主程序包中調用駐留在cmp中的業務邏輯，并按需使用util，config和model。 對于cli和xml輸出的實現所在的輸出包，情況也是如此。 計算后，此軟件包將使用配置以及模型。

結論

軟件包不應是二等公民，而是可以幫助您構建應用程序的結構，以便輕松查看代碼和單獨的功能。 諸如structure101之類的工具可幫助您分析軟件包之間的依賴關系，因此使軟件包成為一側的jar和另一側的類之間的重要層次。

參考：在Martin's Developer World博客上，我們的JCG合作伙伴 Martin Mois 使用structure101分析了軟件包的依賴關系 。

翻譯自: https://www.javacodegeeks.com/2013/11/analyze-package-dependencies-with-structure101.html

structure101

總結

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

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