Search code examples
c++design-patternsaggregationcompositiondependency-inversion

Dependency inversion principle: trying to understand


I'm learning design patterns and things around it (like SOLID and Dependency inversion principle in particular) and it looks like I'm loosing something:

Following the DIP rule I should be able to make classes less fragile by not creating an object in the class (composition) but sending the object reference/pointer to the class constructor (aggregation). But this means that I have to make an instance somewhere else: so the more flexible one class with aggregation is, the more fragile the other.

Please explain me where am I wrong.


Solution

  • You just need to follow the idea through to its logical conclusion. Yes you have to make the instance somewhere else, but this might not be just in the class that is one level above your class, it keeps needing to be pushed out and out until objects are only created at the very outer layer of your application.

    Ideally you create all of your objects in a single place, this is called the composition root (the exception being objects which are created from factories, but the factories are created in the composition root). Exactly where this is depends on the type of app you are building.

    • In a desktop app, that would be in the Main method (or very close to it)
    • In an ASP.NET (including MVC) application, that would be in Global.asax
    • In WCF, that would be in a ServiceHostFactory
    • etc.

    this place may end up being 'fragile' but you only have a single place to change things in order to be able to reconfigure your application, and then all other classes are testable and configurable.

    See this excellent answer (which is quoted above)