循环引用有什么问题？

我今天参加了一次编程讨论，在那儿我做了一些声明，这些声明基本上是不合逻辑地假定循环引用（在模块，类之间，无论如何）通常是不好的。一经讲完，我的同事就会问：“循环引用有什么问题？”

我对此有很强烈的感觉，但我很难简洁而具体地表达自己的观点。我可能提出的任何解释都倾向于依赖于我也考虑过公理的其他项目（“不能孤立使用，因此无法测试”，“参与对象中状态发生变化时的未知/不确定行为”，等等。 。），但是我很想听听一个简洁的原因，为什么循环引用很糟糕，却没有我自己的大脑所经历的那种信念飞跃，多年来花了很多时间来弄清它们的理解，修正，并扩展各种代码。

编辑：我不是在问同质的循环引用，就像那些在双链表或指向父母的指针。这个问题的确是在询问“更大范围”的循环引用，例如libA调用libB，后者又回调libA。如果愿意，可将“模块”替换为“库”。到目前为止，感谢您提供所有答案！

循环引用有很多错误：

• 循环类引用创建高耦合 ; 这两个类必须重新编译每次无论是他们的改变。

• 循环装配引用可防止静态链接，因为B依赖于A，但是直到B完成才可以装配A。

• 循环对象引用会使堆栈溢出而使朴素的递归算法（例如序列化程序，访问者和漂亮的打印机）崩溃。更高级的算法将具有周期检测功能，并且只会失败，并带有更具描述性的异常/错误消息。

• 循环对象引用还使依赖项注入成为不可能，从而大大降低了系统的可测试性。

• 具有大量循环引用的对象通常是“ 上帝对象”。即使不是，它们也倾向于导致制定《意大利面条法》。

• 循环实体引用（尤其是在数据库中，但在域模型中也是如此）会阻止使用不可为空的约束，这可能最终导致数据损坏或至少不一致。

• 当试图理解程序的功能时，一般来说，循环引用只会造成混乱，并极大地增加认知负担。

请想想孩子们；尽可能避免使用循环引用。

圆形参考是非圆形参考耦合的两倍。

如果Foo知道Bar，而Bar知道Foo，则您有两件事需要更改（当要求Foos和Bars不再必须彼此了解时）。如果Foo知道Bar，但是Bar不知道Foo，则可以在不触摸Bar的情况下更改Foo。

循环引用还可能导致引导问题，至少在长时间持续的环境（部署的服务，基于图像的开发环境）中，Foo依赖Bar进行工作以进行加载，但是Bar也依赖Foo进行工作以进行引导。加载。

当将两段代码绑定在一起时，实际上就是一大段代码。维护少量代码的困难至少在于其大小的平方，甚至可能更高。

人们经常查看单个类（/函数/文件/等）的复杂性，却忘记了您确实应该考虑最小的可分离（可封装）单元的复杂性。具有循环依赖性可能会在无形中增加该单元的大小（直到您开始尝试更改文件1并意识到这还需要更改文件2-127）。

它们可能不是一个人就坏的情况，而是表明可能的不良设计的指标。如果Foo依赖于Bar，而Bar依赖于Foo，则有理由质疑为什么它们是两个而不是唯一的FooBar。

嗯...这取决于您所说的循环依赖，因为实际上有些循环依赖我认为是非常有益的。

考虑一个XML DOM-每个节点都有对其父级的引用，每个父级都有其子级列表是有意义的。该结构在逻辑上是一棵树，但是从垃圾回收算法或类似的角度来看，该结构是圆形的。

就像鸡肉或鸡蛋的问题。

在许多情况下，循环引用是不可避免的并且很有用，但是例如，在以下情况下，循环引用不起作用：

项目A取决于项目B，而项目B取决于A。需要将A编译为要在B中使用，这需要B在A之前进行编译，而B则需要B在A之前进行编译，而B在A之前...

尽管我同意这里的大多数评论，但我想对“父母” /“孩子”通函进行特殊说明。

一个类通常需要了解有关其父类或所属类的信息，也许是默认行为，数据来自的文件名，选择该列的sql语句或日志文件的位置等。

您可以通过具有一个包含类来实现此操作而无需循环引用，从而使以前的“父级”现在成为同级，但并非总是可以重构现有代码来做到这一点。

另一种选择是将子代可能需要的所有数据传递到其构造函数中，这最终简直太可怕了。

用数据库术语来说，具有正确的PK / FK关系的循环引用使得不可能插入或删除数据。如果您不能从表a中删除，除非该记录从表b中删除，并且您不能从表b中删除，除非该记录是从表a中删除，则无法删除。与插入相同。这就是为什么如果有循环引用，许多数据库不允许您设置级联更新或删除的原因，因为在某些时候，这是不可能的。是的，您可以在不正式声明PK / Fk的情况下建立此类关系，但是（我的经验中有100％的时间）您将遇到数据完整性问题。那只是不好的设计。

我将从建模的角度考虑这个问题。

只要您不添加实际上不存在的任何关系，就可以保证安全。如果确实添加它们，则数据的完整性会降低（因为存在冗余），并且代码耦合度会更高。

具体来说，使用循环引用时，除了一个-自引用，我还没有看到实际上需要它们的情况。如果您对树或图形进行建模，则需要这样做，因为从代码质量的角度来看，自引用是无害的（没有添加依赖项），因此完全可以。

我相信，当您开始需要非自我参考时，应立即询问是否不能将其建模为图形（将多个实体折叠成一个节点）。也许您之间有一个循环参考，但是将其建模为图形是不合适的，但我对此表示高度怀疑。

人们认为他们需要一个循环参考，但实际上并不需要。最常见的情况是“一对多情况”。例如，您有一个具有多个地址的客户，应将其中的一个地址标记为主要地址。将这种情况建模为两个独立的关系has_address和is_primary_address_of很诱人，但这是不正确的。原因是作为主要地址不是用户和地址之间的单独关系，而是它是具有地址的关系的属性。这是为什么？因为其域仅限于用户的地址，而不是那里的所有地址。您选择一个链接并将其标记为最强（主要）。

（现在要谈论数据库）许多人选择双向关系解决方案，因为他们理解“主”是唯一的指针，而外键则是一种指针。因此，外键应该是要使用的东西，对吗？错误。外键表示关系，但“主”不是关系。这是排序的退化情况，其中一个元素高于所有元素，其余元素不排序。如果您需要对总订购进行建模，那么您当然会将其视为关系的属性，因为基本上没有其他选择。但是，当您退化它时，有一种选择和一个非常可怕的选择-将非关系模型化为关系模型。因此，关系冗余无疑是不容小under的。

因此，除非绝对清楚它来自我正在建模的事物，否则我不允许循环引用。

（注意：这与数据库设计略有偏差，但是我敢打赌它也同样适用于其他领域）

我会用另一个问题回答这个问题：

在保持循环参考模型是您要构建的最佳模型的情况下，您能给我什么情况？

根据我的经验，最好的模型几乎不会像我认为的那样涉及循环引用。话虽如此，在很多模型中，您一直都在使用循环引用，这是非常基础的。父级->子级关系，任何图形模型等，但是这些都是众所周知的模型，我认为您是完全在指其他事物。

数据结构中的循环引用有时是表达数据模型的自然方法。在编码方面，它绝对不是理想的，并且可以（在某种程度上）通过依赖注入来解决，从而将问题从代码推向数据。

循环引用构造不仅从设计的角度来看还是有问题的，而且从捕获错误的角度来看也是有问题的。

考虑代码失败的可能性。您尚未在任何一个类中都放置适当的错误捕获，或者是因为您尚未开发方法，或者是您很懒。无论哪种方式，您都不会收到错误消息来告诉您发生了什么，因此您需要对其进行调试。作为一名优秀的程序设计人员，您知道哪些方法与哪些流程相关，因此可以将其范围缩小到与导致错误的流程相关的那些方法。

使用循环引用，您的问题现在增加了一倍。因为您的进程是紧密绑定的，所以您无法知道哪个类可能导致错误，或者错误从何而来导致错误，因为一个类依赖于另一个而另一个依赖。现在，您必须花时间一起测试两个类，以找出哪个类真正导致了错误。

当然，正确的错误捕获可以解决此问题，但前提是您知道何时可能发生错误。而且，如果您使用的是通用错误消息，您的状况仍然不会更好。

一些垃圾收集器很难清理它们，因为每个对象都被另一个对象引用。

编辑：正如下面的评论所指出的，这仅适用于对垃圾收集器的极幼稚尝试，而不是您在实践中会遇到的尝试。

我认为不受限制的引用使程序设计更容易，但是我们都知道某些编程语言在某些情况下缺乏对它们的支持。

您提到了模块或类之间的引用。在这种情况下，这是程序员预先定义的静态内容，并且程序员很可能可以搜索缺乏圆度的结构，尽管它可能无法完全解决问题。

真正的问题在于运行时数据结构中的循环性，其中某些问题实际上无法通过消除循环性的方式来定义。但最终-应该指出的问题是，要求其他条件迫使程序员解决不必要的难题。

我会说这是工具的问题而不是原理的问题。