User Tools

Site Tools


principles:dependency_inversion_principle

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
principles:dependency_inversion_principle [2013-04-03 14:22] – [Evidence] christianprinciples:dependency_inversion_principle [2021-10-18 21:23] (current) – +++ restored +++ christian
Line 6: Line 6:
 ===== Context ===== ===== Context =====
 /* fill in contexts here: */ /* fill in contexts here: */
-  * [[contexts:Object-Oriented Design]] +  * [[contexts:Object-Oriented Design]] 
 +  * [[contexts:API Design]]
  
  
 ===== Principle Statement ===== ===== Principle Statement =====
  
-Depend on abstractions.((Robert C. Martin: //Agile Software Development, Principles, Patterns, and Practices//, p. 129))+Depend on abstractions.((Robert C. Martin: //[[resources:Agile Software Development, Principles, Patterns, and Practices]]//, p. 129))
  
  
 ===== Description ===== ===== Description =====
  
 +A simplified description of DIP is that a variable declaration should always have the (static) type of an abstract class or ''interface''. By doing so a module depends only on this abstraction. The concrete subclass realizing the details is referenced only once, namely when it is instantiated.
 +
 +The more elaborate definition by Robert C. Martin reads as follows:
 +
 +> 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.(({{page>resources:Agile Software Development, Principles, Patterns, and Practices#reference}}))
 +
 +Following this rule leads to "inverted" dependencies compared to classical procedural approaches. The following diagram shows the classical approach. A high-level module ''A'' uses a low-level module ''B''.
 +
 +{{ :principles:dip1.png?70 |}}
 +
 +When applying DIP, both modules depend on the abstraction (note that in UML diagrams all arrows point into the direction of the dependency):
 +
 +{{ :principles:dip2.png?300 |}}
 +
 +''B'' is not depended upon anymore but it depends on another module. This is the inverted dependency.
  
 ===== Rationale ===== ===== Rationale =====
  
 +When DIP is not applied, only the low-level modules can be reused independently. The higher-level modules depend on the others, so trying to reuse them makes it necessary to either also reuse the lower-level modules or to change the higher-level module. The former is often not wanted because reuse is often done in another context where the lower-level modules do not fit. And the latter is error-prone and requires additional work as it requires changes to already working modules.
  
 ===== Strategies ===== ===== Strategies =====
  
   * Apply the [[patterns:Dependency Inversion]] Pattern   * Apply the [[patterns:Dependency Inversion]] Pattern
 +  * Use events, the observer pattern, etc. to remove dependencies
   * Apply other forms of [[glossary:dependency inversion]]   * Apply other forms of [[glossary:dependency inversion]]
   * Have an ''interface'' type for every class   * Have an ''interface'' type for every class
   * Declare only ''interface'' types so that an object variable generally has an ''interface'' as static type and a concrete class as dynamic type   * Declare only ''interface'' types so that an object variable generally has an ''interface'' as static type and a concrete class as dynamic type
 +  * Do not derive classes from concrete ones (i.\,e.\ non-abstract classes) 
 +  * Do not override already implemented methods in subclasses
  
 ===== Caveats ===== ===== Caveats =====
Line 39: Line 59:
 ===== Origin ===== ===== Origin =====
  
-Robert C. Martin//[[http://www.objectmentor.com/resources/articles/oodmetrc.pdf|Object Oriented Design Quality Metrics: an analysis of dependencies]]//+{{page>resources:Object-Oriented Design Quality Metrics#reference}}
  
  
Line 48: Line 68:
 /*  * [[wiki:Examined]]*/ /*  * [[wiki:Examined]]*/
  
-[[wiki:Accepted]]: DIP is part of the well-know [[collections:SOLID]] principle collection.+[[wiki:Accepted]]: DIP is part of the well-known [[collections:SOLID]] principle collection.
  
 /*  * [[wiki:Questioned]]*/ /*  * [[wiki:Questioned]]*/
Line 58: Line 78:
  
   * [[Low Coupling]] (LC): LC aims at reducing the dependencies to other modules. One way to do so is to only depend on abstractions. DIP is about this aspect.   * [[Low Coupling]] (LC): LC aims at reducing the dependencies to other modules. One way to do so is to only depend on abstractions. DIP is about this aspect.
 +  * [[Dependency Abstraction]] (DA) ((Andreas Zwinkau: [[http://beza1e1.tuxen.de/dependency_abstraction.html|Dependency Abstraction]])): While DIP is about inverting dependencies going from lower to higher architecture layers, DA also works on the same layer where an "inversion" is not helpful.
 ==== Specializations ==== ==== Specializations ====
  
Line 76: Line 96:
 ===== Examples ===== ===== Examples =====
  
 +==== Example 1: Furnace ====
  
 +An example for a high-level module is a regulator module of a furnace. The classical approach would result in the regulator depending on a thermometer and a heater. in such a case it would not be possible to reuse the regulator module for regulating the fluid level of a reservoir or the speed of a car. A DIP-compliant solution would result in the regulator just depending on a sensor module and an actuator module and thermometer and header implementing these ''interfaces''. By doing so thermometer, heater, and regulator can be reused independently.
 +
 +This example is taken from (({{page>resources:Agile Software Development, Principles, Patterns, and Practices#reference}})) and slightly modified.
 +
 +==== Example 2: Client Repository ====
 +
 +Let's say the high-level module (your business logic), wants to be able to add or remove users to the database. Instead of it talking to the database directly, it defines an interface called ClientRepository which contains the methods the business logic needs. Then a MySQLClientRepository concretion, implements that interface and uses a database library to submit the queries. Since the interface is decided by the business logic, the high-level policy is protected from changes in the database library. More over, since the interface was defined by the business logic, it does not reveal anything about the underlying implementation, which allows different types of user repositories, such as a WebserviceClientRepository implementation ([[open-closed_principle|OCP]]). Finally the MySQLClientRepository and business logic can be built as well as deployed independently.
 ===== Description Status ===== ===== Description Status =====
 /* Choose one of the following and comment out the rest: */ /* Choose one of the following and comment out the rest: */
-[[wiki:Stub]]+/*[[wiki:Stub]]*/
 /*[[wiki:Incomplete]]*/ /*[[wiki:Incomplete]]*/
-/*[[wiki:Complete]]*/+[[wiki:Complete]]
  
 ===== Further Reading ===== ===== Further Reading =====
  
-  * Robert C. Martin//[[http://www.objectmentor.com/resources/articles/oodmetrc.pdf|Object Oriented Design Quality Metrics: an analysis of dependencies]]// +  * {{page>resources:Object-Oriented Design Quality Metrics#reference}} 
-  * Robert C. Martin//Agile Software Development, Principles, Patterns, and Practices// +  * {{page>resources:Agile Software Development, Principles, Patterns, and Practices#reference}} 
-  * [[http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod|ButUncleBobPrinciples of OOD]]+  * {{page>resources:ButUncleBob -- Principles of OOD#reference}}
   * [[wiki>DependencyInversionPrinciple]]   * [[wiki>DependencyInversionPrinciple]]
   * [[wp>Dependency inversion principle]]   * [[wp>Dependency inversion principle]]
 +
 +===== Discussion =====
 +
 +Discuss this wiki article and the principle on the corresponding [[talk:principles:Dependency Inversion Principle|talk page]].
  
principles/dependency_inversion_principle.1364991772.txt.gz · Last modified: 2013-05-20 12:46 (external edit)