稳定应用程序的一个关键是结构良好的代码库。 我们知道我们应该建立尽可能多的黑匣子，因为一旦完成一个黑匣子，我们就不必再考虑它的内部了。 您只需要使用您或其他团队成员通过明确定义的界面编写的代码即可。 这使您可以专注于要添加的下一个功能。

当我们想到黑匣子时，我们经常会想到类或整个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和另一侧的类之间的重要层次。

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