structure101

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

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

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

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

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

當(dāng)我們仔細查看這三個程序包之間的糾纏時，我們發(fā)現(xiàn)util程序包中使用了cmp程序包中的類AccessModifier：

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

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

結(jié)論

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

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

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

structure101

總結(jié)

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

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