循环引用是否有必要？

Question

我已经继承了一个Visual Studio解决方案，其中包含众多项目之间的循环引用。

是否有过这种情况，这是远程可接受的？

只是想确认我的怀疑，这个应用程序设计非常可怕。提前致谢。

Answer 1

我曾经读过一篇专栏文章，他们比较了3种模型：意大利面条模型，烤宽面条模型和馄饨模型。

在意大利面条模型中，所有的代码是相互联系的，没有明确的结构。这太可怕了，我们可能都会同意这一点。

在千层面模型中，代码被分成不同的层，只有更高层可以访问低层，而不是相反。

在馄饨模型，代码分组在较小的模块。每个模块只公开需要暴露的内容，但每个模块仍然可以访问每个其他模块。

大约10年前，在我看来，馄饨模型比烤宽面条模型更好。毕竟，在Java中，您还有可以轻松调用对方的Java模块（并且我的印象是所有不同的Java模块之间没有真正的结构）。对我来说，宽面条模型似乎是非面向对象的旧代码的结果，而馄饨模型似乎更现代化，更面向对象。

现在，我倾向于回到烤宽面条模型，但内置了Ravioli模型。这是：

• 应用程序使用不同的层在宽面条模型
• 但层内，代码仍在分裂不同模块之间可在馄饨相互访问，如内置，像模型。

某些循环引用可能很难或无法删除。示例如下： 假设您的应用程序中有一个FileWriter类，并且有一个Debug类。 Debug类将需要FileWriter类，因为它需要用调试信息写入文件。另一方面，FileWriter类也可能需要使用Debug类。

请注意，本示例中的循环引用可能已经导致问题（FileWriter类在编写一行时可能调用Debug类，但Debug类使用FileWriter类编写调试信息，result：stack overflow） 。

在这种情况下，通过在Debug类中不使用FileWriter类，而是使用本地iostreams（如果您使用C++进行开发），可以轻松解决问题。在其他情况下，问题可能会更难解决。

Answer 2

循环项目引用是不好的设计的一个标志，应尽可能删除。

我认为保留一个循环引用的唯一理由将是一个背道而驰的问题。即使这样它似乎可以通过使用类型转发器和另一个程序集来修复

Answer 3

好的软件设计成层次明确，界限分明。即：如果你有一个图层，你需要能够清楚地表达它所做的事情，它为什么在那里以及它依赖于什么。循环使得这很难实现，并且通常应该被删除。 （微软花费了大量的精力在Windows 7中通过删除循环来改进Windows的分层。）

只是试图证实我怀疑此应用程序设计非常糟糕。

这肯定会支持这个理论，但国际海事组织，你需要的不仅仅是几个循环引用来得出这个结论。

要回答您的原始问题：是的，循环引用有时可能会有所帮助。相互递归函数是这类事情的一个很好的例子。但是...这是一个安全地隐藏在模块中的循环引用。对于模块间依赖关系，循环依赖通常意味着您的代码没有在模块中正确拆分，这可能需要一些重要的重构来修复。 （包括添加新的抽象以弥补差距等）

Answer 4

具体而言，我建议使用NDepend来检测和避免dependency cycles。从文章

摘录（我写）：组件之间Control component dependencies to gain clean architecture

依赖循环导致通常所说的面条代码或纠结代码。如果组件A依赖于取决于依赖于A的C的B，则组件A不能独立于B和C被开发和测试.A，B和C形成不可分割的单元，一种超级组件。由于规模现象的不经济性，这种超级组件的成本高于A，B和C的成本总和（在Steve McConnell的Software Estimation：揭秘黑色艺术中有详细记载）。基本上，这就意味着开发一个不可分割的代码片的代价会呈指数级增长。

这表明开发和维护1,000 LOC（代码行）的开发和维护500 LOC的成本可能要比开发和维护500 LOC要多三到四倍，除非它可以分成两个独立的500 LOC的块。因此，与意大利面条的比较描述了无法维护的纠结的代码。为了使架构合理化，必须确保组件之间不存在依赖性循环，而且还要检查每个组件的大小是否可接受（500到1000 LOC）。