u3d ab包 循环依赖
如果您很不幸不能在一个项目中与我一起工作，那么您将遭受所有软件包依赖项必须无循环的规则的困扰。 我不仅需要这样做 ，而且还将创建一个单元测试，以确保使用Degraph进行测试。 这就是我认为无周期封装结构对项目有益的原因。
- 有用的抽象 ：如果您在实现内容时没有过多考虑依赖项，则几乎可以肯定会得到循环依赖项。 为了打破这些循环，您通常必须以接口的形式引入新的抽象。 与以前的直接依赖关系相比，这些接口通常可以为应用程序中的操作创建更清晰的抽象，例如考虑两个相互依赖的包Something和Other 。 正如描述的那样，没有办法说出它们为什么相互依赖。 但是为了打破依赖关系之一，您可能决定引入一个接口。 该接口的名称可能包括有关两者之间关系的有价值的附加信息。 想象一下，该接口最终被命名为SomethingDeletionListener ，位于Somehting中并在Other中实现。 这已经告诉您有关两个软件包的关系的信息，不是吗？
- 干净的正交包结构 ：每当您在树状结构中组织某些东西时，您可能都希望在该树中形成正交结构。 这意味着在分支的所有子分支上都是单一分类的元素。 一个很好的例子是Customer ， Order ， Wishlist ，另一个很好的例子是UserInterface ， Persistence ， Domain 。 这些结构清楚地表明了类所属的位置。 如果将这两种方法混合使用，最终会得到诸如Customer ， Order ， Persistence之类的东西。 在这样的结构中，完全不清楚用于持久性客户的类在哪里。 结果是一团糟，通常会导致依赖关系中的循环，因为诸如客户应该依赖于持久性之类的问题或其他方法甚至都没有道理。
- 启用重用 ：是否曾经尝试过重用某个包，甚至是一个不在乎依赖项的项目中的单个类？ 我试过了。 在10个案例中的9个案例中，我有两种选择：要么选择整个项目（实际上不是一个选择），要么对类进行一些繁重的重构，然后再进行编译，而无需在项目中包含所有其他内容。 另一方面，在项目中，程序包的依赖关系形成了一个很好的有向无环图，这很清楚该类需要做什么。 人们对重用感兴趣的东西通常靠近图的叶子，可以自己提取或很少依赖。
- 启用部分重写 ：有时，一个曾经被认为很棒的想法变成了一个非常糟糕的想法。 有时情况很糟，您想重做。 非循环依赖性限制了受更改影响的代码量。 由于具有循环依赖性，整个应用程序通常至少有受到影响的危险。
- 独立部署 ：另一方面，有时想法实际上是很棒的。 也许如此之大以至于它们被大量使用，以至于您需要对其进行扩展并单独部署在三台其他服务器上，以应对沉重的负载。 祝您好运，将您的应用程序分为两个或两个以上的部分，当程序包之间缠结在一起时，可以将它们分开部署。 采用无循环结构，可以切割的地方应该很明显。
翻译自: https://www.javacodegeeks.com/2014/11/five-reasons-why-you-should-keep-your-package-dependencies-cycle-free.html
u3d ab包 循环依赖
