例：
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是我现在最了解的最好的例子,但如果我可能这么大胆,我即将出版的书还将包含一个解决这个问题的部分.
