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