SOLID Series — 5/5 — Dependency Inversion Principle
This article is part of the SOLID series which describes in depth all the S.O.L.I.D. principles, including examples, good practices, what are the common violations and why it benefits the developer and the product itself.
This principle can somehow be considered as a complementary to the Inversion Segregation Principle, as it describes the feature of your code to depend on abstractions and not concrete implementations.
Definition
High-level modules should not depend on low-level modules. Both should depend on abstractions.
and
Abstractions should not depend on details. Details should depend on abstractions.
In short terms, the design should depend on interfaces or behaviors of a program but not their concrete implementations.
Common Pitfalls
Following the same example as in the Interface Segregation Principle, we can consider the same factory that produces devices. The SimpleDevice (which has GSM) has to be connected with a SIM which can allow the device to be connected with the GSM network. In the first approach, we can connect the SimpleDevice with a SIM object and allow the communication between them. But what will happen when in a few years microSIM and nanoSIM will be introduced to the world? We have to create extra functionality to allow the new SIM types.
In the below example we can use the Interface Segregation Principle on the SIM world and define a SIMInterface that generalises the common SIM behavior for all the SIM types and thus a Device can expect this behavior instead of the concrete implementation of it.
This way, we can create all types of SIMs (normalSIM, microSIM and nanoSIM) and allow the device to accept different types according to each case.
Conclusions
This principle once more adds more complexity to your code but it makes it more flexible to new requirements of the clients. It needs experience to understand and create this kind of layered and distributed behavior and it can be difficult to achieve at your first version. Usually it is being implemented after changes in the code are required when the client has new requirements.
Use in combination with common sense and do not over-use it.
Further Reading
If you liked the article let me know by pressing the Recommendation button or even leave a comment to discuss. Feel free to share and discuss your approaches :-)
