问题标签 [circular-dependency]

（Java问题）

如果我引用内部类中的字段，这会导致封闭类和内部类之间的循环依赖吗？

我怎样才能避免这种情况？

这是一个例子：

好的，我有两个模块，每个模块都包含一个类，问题是它们的类相互引用。

比如说，我有一个房间模块和一个包含 CRoom 和 CPerson 的人员模块。

CRoom 类包含有关房间的信息，以及房间中每个人的 CPerson 列表。

然而，CPerson 类有时需要将 CRoom 类用于其所在的房间，例如寻找门，或者查看房间里还有谁。

问题是两个模块相互导入我只是收到一个导入错误，第二个导入的是哪个模块:(

在 c++ 中，我可以通过仅包含标头来解决此问题，并且由于在这两种情况下，类都只有指向另一个类的指针，因此前向声明对于标头就足够了，例如：

除了将两个类放在同一个模块或类似的东西中之外，是否有在 python 中执行此操作？

编辑：添加了显示使用上述类的问题的 python 示例

错误：

回溯（最后一次调用）：
文件“C:\Projects\python\test\main.py”，第 1 行，
从房间导入 Croom
文件“C:\Projects\python\test\room.py”，第 1 行，
从人导入 CPerson
文件“C:\Projects\python\test\person.py”，第 1 行，
从房间导入CRoom
ImportError: cannot import name
CRoom room.py

人.py

您可以构造一个 C++ 程序，以便（几乎）所有代码都驻留在头文件中。它本质上看起来像一个 C# 或 Java 程序。但是，在编译时，您确实需要至少一个.cpp文件来拉入所有头文件。现在我知道有些人绝对会讨厌这个想法。但我没有发现这样做有任何令人信服的缺点。我可以列出一些优点：

[1] 更快的编译时间。所有头文件只被解析一次，因为只有一个 .cpp 文件。此外，一个头文件不能包含多次，否则会导致构建中断。使用替代方法时，还有其他方法可以实现更快的编译，但这很简单。

[2] 它通过使它们绝对清晰来避免循环依赖。如果ClassAin对inClassA.h有循环依赖，我必须提出一个前向引用并且它会突出。（请注意，这与编译器自动解析循环依赖关系的 C# 和 Java 不同。这鼓励了 IMO 的不良编码实践）。同样，如果您的代码在文件中，您可以避免循环依赖，但在实际项目中，文件往往包含随机标题，直到您无法弄清楚谁依赖于谁。ClassBClassB.h.cpp.cpp

你的意见？

我遇到了我认为是我的 PHP 应用程序的循环依赖问题。如果这不正确，请告诉我。情况如下：

两个类，LogManager 和 DBSession。

DBSession 用于与数据库交互，LogManager 用于记录到文件。两者都在我的应用程序中广泛使用。创建 DBSession 实例时，必须通过构造函数参数为其提供 LogManager 实例。这是因为 DBSession 有时会将信息记录到文件中，并且会使用 LogManager 实例来执行此操作。

现在，我想扩展 LogManager 以便它也可以记录到数据库表，而不是文本文件。当然，我更喜欢重用现有的类，但我很快意识到这带来了一个有趣的情况。

DBSession 已经需要一个 LogManager 实例来构建。如果我想在 LogManager 中重用 DBSession 类，它现在需要一个 DBSession 实例。我怎样才能满足这两个要求？显然，我的方法一定有问题。

你会建议我如何解决这个问题？

提前谢谢各位。

我有两个函数之间的循环依赖。我希望这些函数中的每一个都驻留在自己的 dll 中。是否可以使用 Visual Studio 构建它？

-> 应该编译成 foo.dll

-> 应该编译成 bar.dll

我在 Visual Studio 中创建了两个项目，一个用于 foo，一个用于 bar。通过使用“参考”并编译几次，我设法获得了我想要的 dll。但是，我想知道 Visual Studio 是否提供了一种以干净的方式执行此操作的方法。

如果 foo 发生变化，bar 不需要重新编译，因为我只依赖 bar 的签名，而不依赖于 bar 的实现。如果两个 dll 都存在 lib，我可以将新功能重新编译到两者中的任何一个中，整个系统仍然可以工作。

我尝试这样做的原因是我有一个具有循环依赖关系的遗留系统，该系统当前是静态链接的。出于各种原因，我们希望转向 dll。我们不想等到清理完所有循环依赖项。我正在考虑解决方案并在 linux 上使用 gcc 尝试了一些事情，并且可以按照我的建议进行操作。因此，您可以拥有两个相互依赖并且可以相互独立构建的共享库。

我知道循环依赖不是一件好事，但这不是我想要的讨论。

我正在寻找一种好的模式来解决 Windows 窗体应用程序中的以下循环引用：

• 程序集 1 包含一个带有 Infragistics 菜单项“.显示”程序集 2 中的表单的 Windows 窗体
• 程序集 2 包含一个带有 Infragistics 菜单项“显示”程序集 1 中的表单的 Windows 窗体

菜单在整个应用程序中通常具有相同的项目。因此，Assembly 1 和 Assembly 2 都相互引用以“新建”彼此的表格并显示它们。

关于大小的说明：我的应用程序是一个现有的应用程序，所以情况并不像上面两个组装的情况那么简单。但是，如果我可以简单地解决上述问题（可能不实现 a ，我可以将其应用于更大的应用程序（大约 20 个组件，所有组件都有几种跨组件相互弹出的表单）。

我已经考虑了一些解决方案，但它们似乎都很麻烦。我缺少一个简单的解决方案吗？

假设我们有两个类，Foo 和 Foo Sub，每个类分别位于不同的文件 foo.rb 和 foo_sub.rb 中。

foo.rb：

foo_sub.rb：

由于循环依赖，这不会起作用——我们不能在没有另一个的情况下定义任何一个类。我见过各种解决方案。我想避免其中两个——即将它们放在同一个文件中并删除循环依赖。因此，我发现的唯一其他解决方案是前向声明：

foo.rb：

foo_sub.rb

不幸的是，如果我有三个文件，我将无法完成相同的工作：

foo.rb：

foo_sub.rb：

foo_sub_sub.rb：

如果我需要 foo_sub.rb，那么 FooSub 是 foo_sub_sub.rb 中未初始化的常量。任何想法如何在不将它们放在同一个文件中或删除循环依赖的情况下解决这个问题？

我正在尝试解决 Windows 窗体应用程序中的内存泄漏问题。我现在正在查看一个包含多个嵌入式表单的表单。让我担心的是，子表单在其构造函数中引用了父表单，并将其保存在私有成员字段中。所以在我看来，垃圾收集时间到了：

父通过控件集合引用子表单（子表单嵌入其中）。子表单不是 GC'd。

子表单通过私有成员字段引用父表单。父表单不是 GC'd。

这是对垃圾收集器如何评估情况的准确理解吗？有什么方法可以“证明”它以用于测试目的？

我正在设计一个可重用的类库，其中包含 2 个名为 core.xml.dll 和 core.string.dll 的程序集（其中包括）。

xml 程序集引用字符串程序集，以便使用一些字符串辅助方法。

但是，现在有一个字符串方法可以从使用 xml 程序集中包含的方法中受益。

如果我从字符串程序集引用 xml 程序集，我将创建一个循环依赖项，并且将无法从源代码构建这两个程序集。（即鸡和蛋的问题）。

为了遵循“不要重复自己”的原则，我想避免在两个程序集中重复功能。如果我在实现中发现错误，我只想在一个地方修复它。

虽然我可以将程序集合并为一个，但这并不理想，因为它会降低程序集的凝聚力。

我需要重新构建和重新部署整个程序集，只是为了对特定类进行小改动。此外，最终，由于依赖关系如此之多，我最终可能会得到一个巨大的库程序集。

那么在一组可重用的库程序集的上下文中，在这里使用的最佳方法是什么？另外，.NET 框架本身是如何处理这个问题的？

（在 Reflector 中，System.Configuration.dll 似乎引用了 System.XML.DLL，反之亦然。这实际上是否正确，如果是这样，如何管理循环依赖关系？）

我经常发现自己在一个 C++ 项目中面临多个编译/链接器错误，这是由于一些糟糕的设计决策（由其他人做出的 :)）导致不同头文件中的 C++ 类之间的循环依赖关系（也可能发生）在同一个文件中）。但幸运的是（？）这种情况发生的频率并不高，让我在下次再次发生时记住这个问题的解决方案。

因此，为了便于将来回忆，我将发布一个具有代表性的问题和解决方案。当然欢迎更好的解决方案。

• A.h

  /li>

• B.h

  /li>

• main.cpp

  /li>