Das grundlegende Prinzip

---

Das grundlegende Prinzip tragender Architekturen ist schnell erläutert: Ein System muss auf allen Skalen in Schichten von Subsystemen unterteilbar sein. Die Subsysteme der Schicht S_n des Gesamtsystems besitzen dabei keine Abhängigkeiten untereinander und keine Abhängigkeiten zu Schichten S_m mit m > n.

Die Wahl der Subsysteme, ihrer Schichtung und ihrer (erlaubten) Abhängigkeiten untereinander sollte zu allen Zeiten im Projekt änderbar sein. Auf allen Skalen heißt: auf jedes Subsystem muss die gleiche Strategie der Unterteilung in Schichten und Subsubsysteme wieder anwendbar sein. Die rekursive Unterteilung in Schichten und Subsysteme endet also, wenn die Subsysteme so klein sind, dass ihre Funktion klar beschrieben werden und ein Mensch sie ohne Probleme sichten, verstehen und warten kann. Bei Java und vielen anderen Sprachen ist das gewöhnlich die Paket-Ebene, ab der eine weitere Unterteilung in Subsysteme unnötig ist.

Abhängigkeiten

---

Das oben skizzierte Bild kann umgesetzt werden wenn Abhängigkeiten zwischen Subsystemen umkehrbar sind. Das ist mit der Hilfe von Interfaces immer möglich - Interfaces sind exakt für diesen Einsatzzweck geschaffen. Zum Beweis genügt es sich klarzumachen, dass eine gerichtete Abhängigkeit zwischen zwei Subsysteme A und B über die Einführung von Interfaces immer umgekehrt werden kann. Im Beispiel ruft A Funktionalität von B auf. Offenbar kennt A Implementierungsdetails von B, A hat Abhängigkeiten zu B:

A -> B

Ziel ist es nun diese Abhängigkeit zwischen A und B umzukehren. Es werden in B zunächst Interfaces I deklariert, die die Abhängigkeiten abdecken. Formal sind B' und I das, was vorher B war:

A -> (I <- B')

Nun werden die I in A integriert und aus A wird A':

(A -> I) <- B'
      A' <- B'

B' nutzt Implementierungsvorlagen in A' und in der Tat kennt A' keine Implementierungsdetails in B'. Das Ziel ist erreicht, aber: ein neuer Punkt kommt ins Spiel - lesen Sie weiter.

Dependency Injection

---

Vor der Refaktoringmaßnahme ist B von A gerufen worden. Die Umkehr der Abhängigkeit durch die beschriebene Refaktorisierung wird das nicht ändern. Aus A' wird nun Code von B' gerufen, da A' nichts von B' weiß muss eine dritte Komponente B' in A' bekannt gemachen. Dieses Bekanntmachen erfolgt innerhalb einer Initialisierungsphase mit der Hilfe einer Infrastruktur, die sowohl A' als auch B' kennt. Streng genommen hat man also die unerwünschte Abhängigkeit verlagert an eine andere Stelle in der Hoffnung, sie dort besser beherrschen zu können.

Der beschriebene Vorgang wird Dependency Injection genannt und das nächste Kapitel listet Strategien für Dependency Injection, hier zunächst eine Zusammenfassung:

• Eine Architektur trägt, wenn sie in Schichten mit Subsystemen unterteilt werden kann. Die Subsysteme einer Schicht sind unabhängig voneinander, die Abhängigkeiten der Schichten gehen nur in eine Richtung.
• Der Prozess der Unterteilung in Subsysteme muss bis zur gewünschten Granularität rekursiv auf die Subsysteme anwendbar sein.
• In der Praxis müssen für die Umsetzung von Architekturentscheidungen Abhängigkeiten vertauscht werden. Mit der Hilfe von Interfaces, die ein Verhalten vorgeben aber keine Implementierungsdetails erzwingen, kann das geschehen. Interfaces sind für diesen, und nur für diesen Zweck eingeführt worden.
• Die Vertauschung von Abhängigkeiten erzwingt den Einsatz einer Infrastruktur, die in einer Initialisierungsphase konkrete Implementierungen von Interfaces an Interessenten verteilt. Diesen Vorgang nennt man Dependency Injection.

Richten Sie in einem Projekt also Ihre Aufmerksamkeit auf die Art und Weise, wie Dependency Injection organisiert ist. Fehlt Dependency Injection, dann können Sie mit Gewissheit davon ausgehen, dass es im Projekt Architekturprobleme gibt. Vor diesem Hintergrund wundert es, dass Java und viele andere Sprachen keinen build in Mechanismus für Dependency Injection zur Verfügung stellt.

Referenzen

---

Der Klassiker zum Thema von Martin Fowler
Dependency Injection mit Java EE 5