依赖注入来解决循环依赖关系

Question

示例：

class MyClass
{
    Composition m_Composition;

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

我有兴趣在这里使用注射法。因此，我将不得不将构造函数重构为如下所示：

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

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

依赖容器能解决这个问题吗？它应该这样做吗？

还是从一开始就设计得很糟糕？

Answer 1

No，DI容器不会解决循环依赖项-实际上，当您试图解决依赖关系时，它会抛出异常来抗议它。

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

作为一条经验法则，循环的退步是一种设计气味。如果可以的话，可以考虑一种替代设计，在这种设计中，您可以摆脱循环依赖--这也会给您提供更少耦合的。一些可能的重新设计备选方案：

• 使用events从一个类向另一个类发送信号。循环依赖通常已经向一个方向发展，当这种情况发生时，将这个信令API的一部分建模为事件可能会减少循环。
• 如果上述情况属实，但您认为事件似乎是错误的，则可以考虑应用观察者模式。
• 如果通信必须双向进行，则可以使用组件可以通过的中介人进行通信。

但是，我特意选择了嗅觉这个词，而不是反模式，因为在某些情况下(特别是在处理外部定义的API时)，循环依赖是无法避免的。

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

这个其他答案是我目前所知道的最好的、可用的例子，但是如果我敢说的话，我即将出版的书也将包含一个专门讨论这个问题的章节。