Java包之间的每个循环引用都是坏的吗？

Question

我一直在使用Sonar代码质量管理平台,并且在大多数情况下,我发现它非常有助于揭示我的代码库的隐藏设计缺陷.

但是,有一条规则让我比帮助更烦恼,那就是检查"循环包参考"违规行为.

我想我完全理解pacakges之间的这种依赖性是一件坏事.例如,在典型的3层表示/服务/持久性分层设计中,让数据库处理代码具有对UI相关类的引用几乎总是一个坏主意.把它称为'违规'我没问题.

但是让我们考虑其他情况,即像设计类似应用程序的IDE.比如,我们有一个包含Application接口的主包,它定义了List Application.getViews()方法来引用应用程序的视图.

但是,当View接口有一个Application getApplication()方法来引用它的父应用程序时,我认为这是一个非常常见的设计,它将引入一个循环引用,前提是每个接口都在com.myapp.ui中分隔和com.myapp.ui.view分别.

当然,您可以将View界面放入com.myapp.ui来打破循环.但是当你在com.myapp.ui.view中有各种其他视图相关的APIS时,其中许多是另一个抽象的API,比如AbstractView,ContentView,AbstractContentView等,我想知道为了管理目的将它们保存在单独的包中是否更明智.

并且考虑到所述应用程序还有许多其他类似的情况,例如com.myapp.ui.action,com.myapp.ui.perspective等,如果我们要将它们全部放在那里,这将真正使com.myapp.ui pacakge拥挤.

那么,您建议采用什么方法来处理这种情况？真的每个循环包都引用了一件坏事吗？或者,如果我不得不忍受它们,你如何配置Sonar只检查真实的,有问题的周期？

谢谢!

Answer 1

每一个绝对 - 除了这一个;) - 在某些时候会出错.那么,每个循环参考都不好吗？不,你必须使用你的判断.

但是如果你确实引入了循环依赖,那么值得问你是否真的需要它,以及为什么.tl; dr往往是,你可能会发现打破循环可以提高你的模块性,特别是你分别测试组件的能力.

要使用你的例子,一个视图真的需要一个getApplication(),它可能会返回一个相对"重"的对象(即一个本身需要数据库,网络等等)？也许 ......但也许不是.如果您真正需要的getApplication是具有一些回调(例如当用户启动某些操作时),那么在该回调的某个公共包中创建接口可能会很有用.所以,而不是:

com.foo.app.Application
com.foo.view.View
    Application getApplication()

你有:

com.foo.common.Callback // maybe just a Callable, Runnable, etc?
com.foo.app.Application
    provides a Callback for some action foo
com.foo.view.View
    Callback getFooCallback()

你应该问的问题是:这给了我什么？这可能是你必须非常存在,以至于它不会给你太多 - 尽管这可能暗示你可以将你的课分开一些.但实际上它可能会更容易测试你的视图,因为现在你的单元测试可以(1)测试视图而不需要启动整个应用程序,并且(b)提供一个"虚拟"回调,它可以像保存一样描述该操作的字符串,然后您的单元测试断言它保存了正确的字符串.