Loading content
Dependency Injection ist ein Entwurfsmuster zur Entkopplung von Komponenten, bei dem Abhängigkeiten von außen bereitgestellt werden. Dadurch steigen Testbarkeit, Modularität und Wiederverwendbarkeit, weil Objekterstellung und -konfiguration vom Verbrauchscode getrennt sind. Einsatzgrenzen, Lebenszyklen und Komplexität sollten bei der Gestaltung beachtet werd…
Nutze diesen Steckbrief, um den Baustein kurz zu verstehen, ihn im Modell einzuordnen und bei Bedarf in die 360°-Bewertung zu wechseln.
Theoretisches Gebilde: erklärt einen Begriff, ein Prinzip oder ein Denkmodell.
Was du verstehen musst, um ein Themenfeld sinnvoll zu denken.
Dependency Injection ist ein Entwurfsmuster, bei dem eine Komponente ihre benötigten Abhängigkeiten von außen erhält statt sie selbst zu erzeugen. So werden Erzeugung, Konfiguration und Nutzung voneinander getrennt.
Der Ansatz entstand in der objektorientierten Softwareentwicklung aus dem praktischen Problem, stark gekoppelte Klassen und Funktionen schwer austauschbar und testbar zu machen. Im Umfeld von Inversion of Control und leichten Containern wurde die externe Bereitstellung von Abhängigkeiten als Mittel zur Entkopplung breit diskutiert; Martin Fowlers Artikel von 2004 machte Dependency Injection dafür anschlussfähig. Im Kern geht es um Verdrahtung, Konfiguration und Testbarkeit modularer Systeme.
Stell dir DI wie eine Steckleiste in der Architektur vor: Die Komponente definiert nur, welche Anschlüsse sie braucht. Ein äußerer Injector übernimmt die Verdrahtung, wählt konkrete Implementierungen aus und reicht sie meist über den Konstruktor hinein. So bleibt die Fachlogik unabhängig, während Austauschpunkte wie Datenbank, Logger oder API-Client in der Zusammensetzung liegen.
Ein benötigter Dienst, ein Objekt oder eine Funktion, die die Komponente selbst nicht erzeugt.
Die äußere Stelle, die konkrete Implementierungen bereitstellt und Objektgraphen zusammensetzt.
Pflichtabhängigkeiten werden beim Erzeugen übergeben und sind damit früh sichtbar.
Der Verbrauchscode hängt von einem Vertrag oder einer Schnittstelle, nicht von einer konkreten Klasse.
Die Umgebung bestimmt, wann Instanzen erzeugt, geteilt oder neu aufgebaut werden.
DI ist hilfreich, wenn Komponenten austauschbar bleiben sollen, verschiedene Umgebungen unterschiedliche Implementierungen brauchen oder Tests reale Infrastruktur durch Doubles ersetzen sollen. Besonders nützlich ist es in mittelgroßen bis großen Anwendungen mit klaren Schnittstellen. Bei kleinen Programmen kann die zusätzliche Indirektion unnötige Komplexität, mehr Konfiguration und stärkere Framework-Abhängigkeit erzeugen.
Wo dieser Baustein im Themenmodell verortet ist.
Keine Strukturpfade verfügbar.
Erkunde, wie dieser Wissensbaustein mit Konzepten, Methoden, Technologien und Tools verbunden ist.
Diese Quellen belegen den Begriff und seine fachliche Bedeutung.
Alle direkten Verbindungen des aktuellen Wissensbausteins in einer kompakten, textuellen Darstellung.
Diese Einordnung zeigt, in welchem Kontext der Baustein typischerweise relevant wird, wie anspruchsvoll er ist und welche Wirkung er im Modell hat.
Die Ebene innerhalb der Organisation (Unternehmen, Domäne, Team), auf der der AssetBlock angewendet wird.