principles:dependency_inversion_principle
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
principles:dependency_inversion_principle [2021-09-02 12:22] – old revision restored (2021-05-19 11:18) 65.21.179.175 | principles:dependency_inversion_principle [2021-09-02 12:22] – old revision restored (2021-05-19 11:18) 65.21.179.175 | ||
---|---|---|---|
Line 6: | Line 6: | ||
===== Context ===== | ===== Context ===== | ||
/* fill in contexts here: */ | /* fill in contexts here: */ | ||
- | * [[contexts: | + | * [[contexts: |
- | * [[contexts: | + | |
===== Principle Statement ===== | ===== Principle Statement ===== | ||
- | |||
- | Depend on abstractions.((Robert C. Martin: // | ||
===== Description ===== | ===== Description ===== | ||
- | A simplified description of DIP is that a variable declaration should always have the (static) type of an abstract class or '' | ||
- | |||
- | 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> | ||
- | |||
- | Following this rule leads to " | ||
- | |||
- | {{ : | ||
- | |||
- | When applying DIP, both modules depend on the abstraction (note that in UML diagrams all arrows point into the direction of the 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: | ||
- | * Use events, the observer pattern, etc. to remove dependencies | ||
- | * Apply other forms of [[glossary: | ||
- | * Have an '' | ||
- | * Declare only '' | ||
- | * Do not derive classes from concrete ones (i.\,e.\ non-abstract classes) | ||
- | * Do not override already implemented methods in subclasses | ||
- | |||
- | ===== Caveats ===== | ||
- | |||
- | It is normally not helpful to apply DIP to [[patterns: | ||
- | |||
- | Furthermore note that applying [[patterns: | ||
- | |||
- | See section [[#contrary principles]]. | ||
===== Origin ===== | ===== Origin ===== | ||
- | |||
- | {{page> | ||
===== Evidence ===== | ===== Evidence ===== | ||
/* Comment out what is not applicable and explain the rest: */ | /* Comment out what is not applicable and explain the rest: */ | ||
- | + | /* | |
- | /* * [[wiki: | + | * [[wiki: |
- | /* * [[wiki: | + | * [[wiki: |
- | + | | |
- | [[wiki: | + | * [[wiki: |
- | + | */ | |
- | /* * [[wiki: | + | |
===== Relations to Other Principles ===== | ===== Relations to Other Principles ===== | ||
Line 88: | Line 48: | ||
* [[Model Principle]] (MP): DIP demands having abstractions. MP tells how these abstractions can look like. | * [[Model Principle]] (MP): DIP demands having abstractions. MP tells how these abstractions can look like. | ||
+ | * [[Encapsulate the Concept that Varies]] (ECV): | ||
==== Principle Collections ==== | ==== Principle Collections ==== | ||
Line 94: | Line 55: | ||
{{page> | {{page> | ||
- | ===== Examples | + | ===== Example |
- | + | ||
- | ==== 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 \lstinline!interfaces!. By doing so thermometer, | + | |
- | + | ||
- | This example is taken from (({{page> | + | |
===== 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: | + | [[wiki: |
/ | / | ||
- | [[wiki: | + | /*[[wiki: |
===== Further Reading ===== | ===== Further Reading ===== | ||
- | * {{page> | ||
- | * {{page> | ||
- | * {{page> | ||
- | * [[wiki> | ||
- | * [[wp> | ||
- | |||
- | ===== Discussion ===== | ||
- | Discuss this wiki article and the principle on the corresponding [[talk: |
principles/dependency_inversion_principle.txt · Last modified: 2021-10-18 21:23 by christian