我一直在使用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只检查真实的,有问题的周期？
谢谢!