In object-oriented programming, the dependency inversion principle refers to a specific form
of decoupling software modules.
When following this principle, the conventional dependency relationships established from
high-level, policy-setting modules to low-level, dependency modules are inverted, thus rendering
high-level modules independent of the low-level module implementation details.
The principle states:
A. High-level modules should not depend on low-level modules.
Both should depend on abstractions.
B. Abstractions should not depend on details.
Details should depend on abstractions.
The principle inverts the way some people may think about object-oriented design, dictating
that both high- and low-level objects must depend on the same abstraction.
Description In conventional application architecture,
lower-level components are designed to be consumed by higher-level components which
enable increasingly complex systems to be built.
In this composition, higher-level components depend directly upon lower-level components
to achieve some task.
This dependency upon lower-level components limits the reuse opportunities of the higher-level
components.
The goal of the dependency inversion principle is to decouple application glue code from
application logic.
Reusing low-level components becomes easier and maintainability is increased.
This is facilitated by the separation of high-level components and low-level components into separate
packages/libraries, where interfaces defining the behavior/services required by the high-level
component are owned by, and exist within the high-level component's package.
The implementation of the high-level component's interface by the low level component requires
that the low-level component package depend upon the high-level component for compilation,
thus inverting the conventional dependency relationship.
Various patterns such as Plugin, Service Locator, or Dependency Injection are then employed
to facilitate the run-time provisioning of the chosen low-level component implementation
to the high-level component.
Applying the dependency inversion principle can also be seen as applying the Adapter pattern,
i.e. the high-level class defines its own adapter interface which is the abstraction
that the other high-level classes depend on.
The adaptee implementation also depends on the adapter interface abstraction while it
can be implemented by using code from within its own low-level module.
The high-level has no dependency to the low-level module since it only uses the low-level indirectly
through the adapter interface by invoking polymorphic methods to the interface which
are implemented by the adaptee and its low-level module.
History The dependency inversion principle was postulated
by Robert C. Martin and described in several publications including the paper Object Oriented
Design Quality Metrics: an analysis of dependencies, an article appearing in the C++ Report in
May 1996 entitled The Dependency Inversion Principle, and the books Agile Software Development,
Principles, Patterns, and Practices, and Agile Principles, Patterns, and Practices in C#.
See also Adapter pattern
Dependency Injection Interface
Inversion of Control Plug-in
Service locator pattern SOLID
References
External links Object Oriented Design Quality Metrics: an
analysis of dependencies Robert C. Martin, C++ Report, Sept/Oct 1995
The Dependency Inversion Principle, Robert C. Martin, C++ Report, May 1996
Examining the Dependency Inversion Principle, Derek Greer
DIP in the Wild, Brett L. Schuchert, May 2013 IoC Container for Unity3D – part 2