Technical Articles

The DIP principle states:
1.High-level modules should not depend on low-level modules. Both should depend on abstractions.
2.Abstractions should not depend upon details. Details should depend upon abstractions.

In above fig, Procedural designs exhibit a particular kind of dependency structure. This structure starts at the top and points down towards details. High level Modules depend upon lower level modules, which depend upon yet lower level modules,etc.This dependency structure is weak.The high level modules deal with the high level policies of the application. These policies generally care little about the details that implement them. Why then, must these high level modules directly depend upon those implementation modules?

One motivation behind the DIP is to prevent you from depending upon volatile modules. The DIP makes the assumption that anything concrete is volatile. While this is frequently so, especially in early development, there are exceptions. For example, the string.h standard C library is very concrete, but is not at all volatile. Depending upon it in an ANSI string environment is not harmful.Likewise, if you have tried and true modules that are concrete, but not volatile,depending upon them is not so bad. Since they are not likely to change, they are not likely to inject volatility into your design.
Take care however. A dependency upon string.h could turn very ugly when the requirements for the project forced you to change to UNICODE characters. Non-volatility is not a replacement for the substitutability of an abstract interface.