Dependency Injection considered useful

Veröffentlicht: 12. August 2011 von pmischke in Dependency Injection

Im folgenden möchte ich gerne den Übergang vom letzten Eintrag Dependency Inversion Principal (DIP) zum Dependency Injection (DI) Container schaffen. Mit dem Titel meines Posts beziehe ich mich auf

Der Post von Nat Pryce ist ein wenig provokant aufgezogen und führte daher zu viel Diskussion in der Kommentar Sektion. Das abschließende Fazit von Nat lautet

Let me clarify… the title — „Dependency Injection“ considered harmful — refers to the fact that I consider the term „Dependency Injection“ harmful — it is misleading and as a result DI frameworks often do not actually do DI at all because they focus on „injection“ and not the clear, explicit management of dependencies between objects.

Zum einen geht es Nat also um die Wahl des Namens. Insbesondere um den Ausdruck „Injection“ für die Technologie, sprich die DI Container. Aber noch wichtiger kritisiert er, dass in Folge dessen die DI Container nicht dazu genutzt werden, die OO Konzepte hinter DI umzusetzten. Das sind Konzepte wie eben das DIP und die im Post genannten Verweise auf das GOOS Buch. Stattdessen wird die Technologie ohne Rücksicht auf die Konzepte verwendet. Im Gegenteil werden durch die Technologie sogar OO Prinzipien wie Kapselung ausgehebelt.

In das gleiche Horn stößt

Die wichtige Aussage von Mark Seemann in diesem Zusammenhang ist

What’s really lacking, at least in the .NET world, is an understanding that DI is really about principles and patterns, and not about technology.

As .NET developers we have been raised by Microsoft to believe that every problem can be addressed with a tool. When it comes to loose coupling, DI Containers look like enabling technology, but it’s really, really important to realize that the solution doesn’t lie with the tool. It lies in the understanding that DI (or Inversion of Control) is a fundamentally different way to reason about and design software.

This relates very closely to the SOLID principles – in fact, DI is just an elaboration of the ‚D‘ in SOLID, so it’s far from new knowledge. In my opinion, SOLID very nicely captures the essence of OOP, and if you write SOLID code, you also utilize DI. Technology in the shape of a container is totally optional at this point.

Auch Mark sagt, dass wichtige an DI sind die Konzepte, insbesondere das D aus den SOLID Prinzipien, also das DIP. Im übrigen ist der Irrglaube der heilbringenden Technologie in der Java Welt genauso verbreitet.

Fassen wir also zusammen: OO Konzepte wie das DIP sind notwendige Voraussetzung für erfolgreiche Anwendung von Dependency Injection. Bis zu dieser Stelle sind Nat, Mark, wahrscheinlich viele andere auch und ich alle der selben Meinung. Bei der Rolle der Technologie in Form des DI Containers gehen die Meinungen jedoch auseinander.

Nat hält den Container für eine Behinderung. Darum verzichtet er ganz auf ihn und schreibt die separierten Kompositionslogik lieber selbst. Die Kompositionslogik ist dadurch klar in Code ausgedrückt, gut sichtbar und unterliegt dem normalen Refactoring. Die Argumente sind durchaus nachvollziehbar. Ja, es ist wichtig, die Abhängigkeiten explizit im Code auszudrücken. Daher befürworte ich, dass die JSR-330 DI Container die @Inject Annotation am Konstrutor erzwingen, auch wenn man das per Konvention regeln könnte, wie es einige .NET DI Container machen. Auf die Idee, die Kompositionslogik selber zu schreiben, würde ich nicht kommen. In der Kompositionslogik finden sich wiederkehrende Muster. Zum Teil sind diese Muster bereits hier und da dokumentiert, zum Teil auch nicht (Vielleicht ist das ein oder andere Muster demnächst in diesem Blog zu finden 🙂 ). Wie dem auch sei, sollte man die wiederkehrende Logik doch allgemein und wiederverwendbar lösen und nicht in jeder Anwendung neu. Das ist doch genau die Leistung des DI Containers, oder?

Mark beschäftigt sich sehr intensiv mit Containers, hat ein Buch dazu in Vorbereitung. Das ist alles andere als Ablehnung. Dennoch hält er den DI Container für optional (siehe Zitat oben).

Und wie stehe ich zu DI Containern? Natürlich kann der DI Container missbraucht werden, wie jede Technologie. Aber die Möglichkeit zum Missbrauch ist für mich noch kein Grund zur Ablehnung. Sauberes OO Design ist nach wie vor die notwendige Voraussetzung für ein nachhaltiges System. Der DI Container kann meiner Erfahrung nach zum Katalysator für gutes OO Design werden und macht sich damit zum Pflichtbestandteil. Gutes Design kommt schließlich nie zum Null-Tarif. Der Aufwand, entkoppelte Module zu komponieren sinkt aber deutlich beim Einsatz eines DI Containers. Mit dem sinkenden Aufwand erhöht sich das Kosten-Nutzen-Verhältnis und damit meine Bereitschaft, diesen Aufwand zu treiben. Der DI Container ist also kein Selbstzweck, sondern Mittel zum Zweck. Der Theorie nach ist er optional, in der Praxis nicht!

Advertisements

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s