- Dependency Inversion Prinzip
-
Das Dependency Inversion Principle (DIP; dt. "Abhängigkeits-Invertierungs-Prinzip") ist ein Prinzip beim Objektorientierten Entwurf von Software. Es beschäftigt sich mit der Abhängigkeit von Modulen.
Im allgemeinen wird das DIP beschrieben durch:
- Module hoher Ebenen sollten nicht von Modulen niedriger Ebenen abhängen.
Beide sollten von Abstraktionen abhängen.
- Abstraktionen sollten nicht von Details abhängen.
Details sollten von Abstraktionen abhängen.
Inhaltsverzeichnis
Problemstellung und Lösung
Objektorientierte Entwürfe werden in Module strukturiert, die unterschiedliche Verantwortlichkeiten umsetzen. Eine gängige Praxis ist das Anordnen der Module in Ebenen. Je niedriger die Ebene eines Modul, desto spezieller sind die Vorgänge, die es definiert. In Modulen höherer Ebenen werden allgemeine Abläufe umgesetzt, welche von Modulen niedrigerer Ebenen benutzt werden.
Falls diese Anordnung falsch umgesetzt wird, also Module höherer Ebenen von Modulen niedrigerer Ebenen abhängen, entsteht ein Problem. Änderungen in Modulen niedrigerer Ebenen führen unweigerlich zu Änderungen im Modulen höherer Ebenen. Dies widerspricht aber einerseits dem eigentlichen Ansatz der Hierarchie, andererseits führt es zu zyklischen Abhängigkeiten. Damit kommt es zu einer erhöhten Kopplung der Module, welche Änderungen in Architektur und Design unnötig verkomplizieren.
Der Lösungsansatz ist die Invertierung der Abhängigkeit. Das Modul der höheren Ebene definiert die Schnittstelle, mit der es arbeitet. Module niedrigerer Ebene realisieren die Schnittstelle.
Beispiel
Wir betrachten ein einfaches Schalter-Lampe-Modell. Das Drücken des Schalters soll die Lampe an- und ausschalten.
Eine einfache Implementierung in Java:
public class Lampe { private boolean leuchtet = false; public void anschalten() { leuchtet = true; } public void ausschalten() { leuchtet = false; } } public class Schalter { private Lampe lampe; private boolean gedrueckt; public Schalter(Lampe lampe) { this.lampe = lampe; } public void drueckeSchalter() { gedrueckt = !gedrueckt; if(gedrueckt) { lampe.anschalten(); } else { lampe.ausschalten(); } } }
Schalter steuert den Ablauf des Verhaltens und benutzt dazu Lampe. Demnach sollte es einem Modul höhere Ebene angehören. Jedoch verletzt das beschriebene Modell DIP, da Schalter abhängig von Lampe ist. Wird entschieden, dass die Methoden von Lampe umbenannt werden, muss auch Schalter geändert werden.
Das grundlegende Problem ist, dass Schalter direkt mit Lampe arbeitet, welches zu einem niedrigeren Modul gehört. Schalter sollte selbst definieren, wie das Objekt aussehen sollte, mit dem es arbeitet.
Die Lösung in Java:
public Interface SchalterKlient { public void geheAn(); public void geheAus(); } public class Schalter { private SchalterKlient klient; private boolean gedrueckt; public Schalter(SchalterKlient klient) { this.klient= klient; } public void drueckeSchalter() { gedrueckt = !gedrueckt; if(gedrueckt) { klient.geheAn(); } else { klient.geheAus(); } } } public class LampeDIP implements SchalterKlient{ private leuchtet = false; public void geheAn() { leuchtet = true; } public void geheAus() { leuchtet = false; } }
Die Schnittstelle SchalterKlient gehört zum gleichen Modul wie Schalter. Spezifischere Module müssen diese Schnittstelle realisieren, damit Schalter mit ihnen arbeiten kann. Somit wurde die Abhängigkeit invertiert.
Zusätzlich zu dem Brechen der Abhängigkeit wurde ein weiterer Vorteil erarbeitet: Schalter kann nun mit beliebigen Klienten arbeiten.
Das Beispiel lässt sich weiterführen. Schalter selbst wird vermutlich von einem anderen Modul aus genutzt, das entscheidet, wann der Schalter gedrückt wurde. Demnach sollte dieses Modul wiederum eine Schnittstelle definieren, die Schalter realisieren muss.
Siehe auch
- Prinzipien Objektorientierten Designs - weitere Prinzipien objektorientierten Designs
Weblinks
Literatur
- Robert C. Martin: The Dependency Inversion Principle. 5/1996
- Module hoher Ebenen sollten nicht von Modulen niedriger Ebenen abhängen.
Wikimedia Foundation.