In most of the applications high level modules are directly linked to low level modules (in other words are dependent on them). High level modules contain most of the time complex logic whereas low level modules serve for basic and primary operations. It is evident that this may lead to dependency problems between those modules.
An application that shows this problem could be structured like this: the Presentation Layer is dependent on the Business Layer which itself is dependant on the Data Layer.
In this layer design, modifications to low level modules force modifications to high level modules that are dependant on them. This leads to high level modules which can not be reused in different technical contexts.
The Dependency Inversion Principle (DIP) therefore explains that high level modules must not depend on low level modules. Both of them have to depend on abstractions. Furthermore abstractions must not depend on details but instead details have to depend on abstractions.
The underlying concept is that abstractions serve as links between high level and low level modules. Abstraction are most of the time expressed via interfaces but the Factory Design Pattern may also be used.
After having applied the principle, the class in the following example is completely independent from other classes, all references being expressed via interfaces.
In the next example, which is based on the Factory Pattern, the class ValidationManagerFactory is used to resolve all dependencies. It associates an object that is implementing the IValidatable interface with an object of type ValidationManager.
The introduction of interfaces allows the inversion of dependencies, which leads in the layers example to layers that are completely independent from each other.
To sum it up, the Dependency Inversion Principle (DIP) provides a high level of flexibility because modules really get reusable easily. All rigid links that may exist between modules are broken up. But by adding a higher level of abstraction, the code gets more complex to understand and to maintain. So this principle must be applied with caution.
5 comments:
I've been following your tutorials about SOLID (and others), they are great, only one remark for this post : images are in french (no matter for me but maybe for others)
Oh oh you are right! But fortunately only the Layer Diagram screenshots!
Here are the translations:
Couche Présentation = Presentation Layer
Couche Métier= Business Layer
Couche Données = Data Layer
Thanks for the comment and stay tuned :)
I call that Inversion of Control (IoC) pattern.
Mehdi
Yes you may also call it like that :) Other wording same meaning :)
I did not understnd how you calling this Validate Mathod. Can you explain it little more in detail.
what is validableObject here?
Post a Comment