Menu
Home
People
Places
Arts
History
Plants & Animals
Science
Life & Culture
Technology
Reference.org
Dependency inversion principle
open-in-new
<p>In <a href="/facts/Object-oriented_design/erWk0mUW">object-oriented design</a>, the dependency inversion principle is a specific methodology for <a href="/facts/Coupling_(computer_programming)/QEeSaXF3">loosely coupled</a> software <a href="/facts/Modular_programming/sNoqKvRD">modules</a>. When following this principle, the conventional <a href="/facts/Dependency_(computer_science)/QEeSaXF3">dependency</a> relationships established from high-level, policy-setting modules to low-level, dependency modules are reversed, thus rendering high-level modules independent of the low-level module implementation details. The principle states: </p> <ol><li>High-level modules should not import anything from low-level modules. Both should depend on abstractions (e.g., interfaces).</li><li>Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.</li></ol> <p>By dictating that both high-level and low-level objects must depend on the same abstraction, this design principle inverts the way some people may think about object-oriented programming. </p><p>The idea behind points A and B of this principle is that when designing the interaction between a high-level module and a low-level one, the interaction should be thought of as an abstract interaction between them. This not only has implications on the design of the high-level module, but also on the low-level one: the low-level one should be designed with the interaction in mind and it may be necessary to change its usage interface. </p><p>In many cases, thinking about the interaction in itself as an abstract concept allows the coupling of the components to be reduced without introducing additional coding patterns, allowing only a lighter and less implementation-dependent interaction schema. </p><p>When the discovered abstract interaction schema(s) between two modules is/are generic and the generalization makes sense, this design principle also leads to the following dependency inversion coding pattern. </p>