Reputation: 53944
Example:
class MyClass
{
Composition m_Composition;
void MyClass()
{
m_Composition = new Composition( this );
}
}
I am interested in using depenency-injection here. So I will have to refactor the constructor to something like:
void MyClass( Composition composition )
{
m_Composition = composition;
}
However I get a problem now, since the Composition
-object relies on the object of type MyClass
which is just created.
Can a dependency container resolve this? Is it supposed to do so?
Or is it just bad design from the beginning on?
Upvotes: 12
Views: 3499
Reputation: 233150
No, a DI Container will not solve a circular dependency - in fact, it will protest against it by throwing exceptions when you try to resolve the dependencies.
In many of the DI Containers you can provide advanced configuration that allows you to overcome this issue, but by themselves they can't resolve circular dependencies. How could they?
As a rule of thumb, a circular depedency is a design smell. If you can, consider an alternative design where you get rid of the circular dependency - this will also give you less coupling. Some possible redesign alternatives:
However, I purposedly chose the word smell over anti-pattern, as there are corner cases (particularly when you deal with externally defined APIs) where circular dependencies cannot be avoided.
In such cases, you need to decide where to loosen the dependency creation slightly. Once you know that, injection of an Abstract Factory may be helpful to defer one of the creations until the other parts of the circle have been created.
This other answer is the best, available example of which I'm currently aware, but if I may be so bold, my upcoming book will also contain a section that addresses this very issue.
Upvotes: 17