Differences

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

--- principles:dependency_inversion_principle [2013-06-17 22:53] – from thesis christian
+++ principles:dependency_inversion_principle [2021-10-18 21:23] (current) – +++ restored +++ christian
@@ Line 68: / Line 68: @@
 /*  * [[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]]*/
@@ Line 78: / 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.
+  * [[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 ====
@@ Line 98: / Line 98: @@
 ==== 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, heater, and regulator can be reused independently.
+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 =====
 /* Choose one of the following and comment out the rest: */
@@ Line 116: / Line 118: @@
   * [[wiki>DependencyInversionPrinciple]]
   * [[wp>Dependency inversion principle]]
+===== Discussion =====
+Discuss this wiki article and the principle on the corresponding [[talk:principles:Dependency Inversion Principle|talk page]].