Themen

Das Dependency-Inversion-Prinzip

Beispiele für seinen Einsatz

Bedeutung im Gesamtkontext der Software-Architektur

Glossar

PDF

Kapitel bei Springer

https://link.springer.com/chapter/10.1007/978-3-662-71607-6_27

• Die Kernaspekte einer Anwendung sollten nicht von ihrer Peripherie abhängen – sondern beide von Abstraktionen.
• Anwendungsentwicklung zielt auf die zugrundeliegenden Abstraktionen und ihre stabilen, abstrakten Schnittstellen.
• Anwendungen bestehen aus klar getrennten Schichten, die Dienste über definierte Schnittstellen bereitstellen.
• Die Anwendungslogik steht im Zentrum. Datenquellen und Nutzerschnittstellen sind peripher.
• Umkehr der Abhängigkeiten sorgt für Unabhängigkeit und intrinsische Testbarkeit der einzelnen Schichten.

Die Kernaspekte einer Anwendung sollten nicht von ihrer Peripherie abhängen – sondern beide von Abstraktionen. Das Ziel aller Softwarearchitektur ist eine flexible Anwendung, die sich einfach erweitern lässt und aus wiederverwendbaren, entsprechend voneinander unabhängigen Komponenten besteht. Entscheidend ist dabei die Richtung von Abhängigkeiten. Der naive Ansatz führt meist zu Abhängigkeiten innerhalb der Software, die in die gleiche Richtung wie der Kontrollfluss zeigen. Soll die aufgerufene Komponente ausgetauscht oder verändert werden, muss in der Regel auch die aufrufende Komponente verändert werden. Das aber widerspricht dem Ziel flexibler, erweiterbarer, letztlich modularer Software.

Der Kerngedanke des Dependency-Inversion-Prinzips (DIP) und gleichzeitig der Grund für seinen Namen ist die Umkehr der üblichen Abhängigkeiten, die parallel zum Kontrollfluss verlaufen. Das führt zu einer Entkopplung von Klassen voneinander und sorgt im Kontext des DIP für eine Modularität auch über Schichtgrenzen einer Gesamtanwendung hinweg.

Anwendungsentwicklung zielt auf die zugrundeliegenden Abstraktionen und ihre stabilen, abstrakten Schnittstellen. Anwendungen bestehen aus klar getrennten Schichten, die Dienste über definierte Schnittstellen bereitstellen. Die Anwendungslogik steht dabei im Zentrum, sowohl Datenquellen als auch Nutzerschnittstellen sind peripher. Diese zunächst ungewohnte Umkehr der Abhängigkeiten sorgt für Unabhängigkeit und intrinsische Testbarkeit der einzelnen Schichten. Die korrekte Anwendung des DIP ist ein grundlegender Mechanismus für die objektorientierte Programmierung – und entscheidet darüber, ob ein Entwurf im eigentlichen Sinn objektorientiert ist oder nicht.

Diese Fragen dienen der persönlichen Beschäftigung mit der Thematik, es werden aber keine Antworten zur Verfügung gestellt.

• Was ist die Kernaussage des Dependency-Inversion-Prinzips?
• Welche Entwurfsmuster sind essentiell für die Umsetzung des DIP?
• Wie unterscheiden sich Open-Closed-Prinzip und DIP voneinander?
• Welche Bedeutung hat das DIP für die objektorientierte Programmierung und insbesondere das Einlösen ihrer Versprechen flexibler, erweiterbarer und wiederverwendbarer Software?
• Welche beiden Prinzipien auf Komponentenebene bilden zusammengenommen das DIP auf Ebene der Gesamtarchitektur? Wie lauten die jeweiligen Aussagen?

Eine kommentierte und handverlesene Liste mit weiterführender Literatur zum Thema. Die Auswahl ist zwangsläufig subjektiv.

Wie alle anderen SOLID-Prinzipien wurde das DIP von Robert C. Martin prägnant formuliert. Vergleiche dazu Kapitel 11 in [Martin, 2003Martin, Robert C. (2003): Agile Software Development. Principles, Patterns, and Practices, Prentice Hall, Upper Saddle River, New Jersey] und Kapitel 11 in [Martin, 2018Martin, Robert C. (2018): Clean Architecture. A Craftman's Guide to Software Structure and Design, Prentice Hall, Boston]. Das Pendant auf höherer architektonischer Ebene, das Zusammenspiel von Stable-Dependencies- und Stable-Abstractions-Prinzip, wird von Robert C. Martin ebenda in späteren Kapiteln formuliert.

Die dem DIP zugrunde liegenden Entwurfsmuster, insbesondere „Abstract Factory“, finden sich im Buch der „Gang of Four“ [Gamma, 1995Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John (1995): Design Patterns. Elements of Reusable Object-Oriented Software, Addison-Wesley, Boston] wieder.

• Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John (1995): Design Patterns. Elements of Reusable Object-Oriented Software, Addison-Wesley, Boston
• Martin, Robert C. (2003): Agile Software Development. Principles, Patterns, and Practices, Prentice Hall, Upper Saddle River, New Jersey
• Martin, Robert C. (2018): Clean Architecture. A Craftman's Guide to Software Structure and Design, Prentice Hall, Boston