依赖注入来解决循环依赖

例:
class MyClass
{
    Composition m_Composition;

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

我有兴趣在这里使用依赖注射.所以我必须重构构造函数,如:

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

但是现在我得到一个问题,因为Composition-object依赖于刚创建的MyClass类型的对象.

依赖关系容器可以解决这个问题吗?应该这样做吗?
还是从一开始就是糟糕的设计?

不,DI容器不会解决循环依赖 – 实际上,当您尝试解析依赖关系时,它将通过抛出异常来抗议它.

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

根据经验,循环遗传是一种设计气味.如果可以的话,考虑一个替代设计,你可以摆脱循环依赖关系 – 这也会减少耦合.一些可能的重新设计备选方案:

>使用事件从一个类到另一个阶段发信号.通常,循环依赖性主要在一个方向进行,并且在这种情况下,将该信令API的一部分建模成事件可能会切割圆.
>如果上述是真的,但是你觉得事件似乎错了,你可以考虑应用Observer模式.
>如果通信必须真正走到两方面,您可以使用组件可以通信的Mediator.

然而,我本来就选择了反模式的气味,因为有一些角落(特别是当你处理外部定义的API)时,不能避免循环依赖.

在这种情况下,您需要确定稍微放松依赖项创建的位置.一旦你知道,注入一个Abstract Factory可能有助于推迟一个创作,直到创建了圆的其他部分.

这个other answer是我现在最了解的最好的例子,但如果我可能这么大胆,我即将出版的书还将包含一个解决这个问题的部分.

相关文章

迭代器模式(Iterator)迭代器模式(Iterator)[Cursor]意图...
高性能IO模型浅析服务器端编程经常需要构造高性能的IO模型,...
策略模式(Strategy)策略模式(Strategy)[Policy]意图:定...
访问者模式(Visitor)访问者模式(Visitor)意图:表示一个...
命令模式(Command)命令模式(Command)[Action/Transactio...
生成器模式(Builder)生成器模式(Builder)意图:将一个对...