依赖注入解决循环依赖

Question

示例：

class MyClass
{
    Composition m_Composition;

    void MyClass()
    {
        m_Composition = new Composition( this );
    }
}

我对在这里使用依赖注入感兴趣。因此，我必须将构造函数重构为以下内容：

void MyClass( Composition composition )
{
    m_Composition = composition;
}

但是，我现在遇到了一个问题，因为 Composition 对象依赖于刚刚创建的 MyClass 类型的对象。

依赖容器可以解决这个问题吗？它应该这样做吗？
或者这只是从一开始就糟糕的设计？

Answer 1

不，DI 容器不会解决循环依赖 - 事实上，当您尝试解决依赖项时，它会通过抛出异常来抗议。

在许多 DI 容器中，您可以提供高级配置来克服此问题，但它们本身无法解决循环依赖关系。他们怎么能呢？

根据经验，循环依赖是一种设计味道。如果可以的话，考虑一种摆脱循环依赖的替代设计 - 这也会给你带来更少的耦合。一些可能的重新设计替代方案：

• 使用事件从一个类向另一个类发出信号。通常，循环依赖大部分都朝一个方向发展，在这种情况下，将此信号 API 的一部分建模为事件可能会缩短循环。
• 如果上述情况成立，但您觉得事件似乎有问题，则可以考虑应用 观察者 模式。
• 如果通信必须真正双向进行，您可以使用 Mediator 组件可以通过它进行通信。

然而，我特意选择了“气味”一词而不是“反模式”，因为在某些极端情况下（特别是当您处理外部定义的 API 时）无法避免循环依赖。

在这种情况下，您需要决定在哪里稍微放松依赖关系的创建。一旦您知道这一点，注入抽象工厂可能有助于推迟其中一项创作，直到圆的其他部分已经创建。

这其他答案是我目前所知的最好的可用示例，但如果我可以如此大胆，我即将出版的书也将包含解决这个问题的部分。