Abhängigkeit Injektionsabhängigkeit?

Question

Gibt es eine Kehrseite? Ich fühle mich jetzt fast abhängig davon. Wann immer ein Projekt eine bestimmte Größe überschreitet, reagiere ich allergisch auf Standardmuster und verdrahte es sofort mit einem Dependency Injection Framework.

Das größte Problem, das ich festgestellt habe, ist, dass es für andere Entwickler, die es gerade erst lernen, verwirrend sein kann.

Außerdem würde ich mich viel wohler fühlen, wenn es ein Teil der Sprache wäre, die ich benutze. Allerdings gibt es zumindest für Java ein paar sehr leichtgewichtige Bibliotheken, die recht gut sind.

Was denken Sie? Schlechte Erfahrungen? Oder einfach aufhören, sich darüber Gedanken zu machen?

---

[EDIT] Re: Beschreibung der Dependency Injection selbst

Tut mir leid, dass ich so vage bin. Martin Fowler beschreibt es wahrscheinlich viel besser, als ich es jemals könnte... kein Grund, sich die Mühe zu machen.

Zufälligerweise bestätigt dies einen Punkt, nämlich dass es immer noch nicht weit verbreitet ist und bei der Arbeit mit Teams ein Hindernis darstellen kann, wenn nicht alle auf dem neuesten Stand sind.

Answer 1

Ich habe versucht, einige der möglichen Nachteile in einem Blogbeitrag hier zu beschreiben: http://kevin-berridge.blogspot.com/2008/06/ioc-and-di-complexity.html

Answer 2

Ich bin ein großer Fan von IO, aber ich habe einige Projekte mit riesigen Xml-Konfigurationsdateien gesehen, die niemand versteht. Hüten Sie sich also vor der Programmierung in Xml.

Answer 3

Außerdem würde ich mich viel besser fühlen, wenn es ein Teil der Sprache wäre, die ich benutze.

FYI gibt es eine sehr einfache und funktionale Dependency Injection als Teil des JDK 6. Wenn Sie leichtgewichtige, unkomplizierte Dependency Injection benötigen, dann verwenden Sie es.

Verwendung von ServiceLoader Klasse können Sie einen Dienst (oder mehrere Implementierungen des Dienstes) auf der Grundlage einer Klasse anfordern:

 package dependecyinjection;  
 import java.util.ServiceLoader;  

 public abstract class FooService {  

     public static FooService getService() {  
         ServiceLoader<FooService> loader = ServiceLoader.load(FooService.class);  

         for (FooService service : loader) {  
             return provider;  
         }  

         throw new Exception ("No service");  
     }  

     public abstract int fooOperation();  

 }  

 package dependecyinjection;  
 public class FooImpl extends FooService {  
     @Override  
     public int fooOperation() {  
         return 2;  
     }  
 }  

Wie definiert ServiceLoader die Dienstimplementierungen, die zurückgegeben werden?

Erstellen Sie in Ihrem Projektordner einen Ordner mit dem Namen META-INF/Dienste und erstellen Sie eine Datei namens dependencyinjection.FooService . Diese Datei enthält eine Zeile, die auf die Implementierung des Dienstes verweist. In diesem Fall: dependecyinjection.FooImpl

Dies ist noch nicht allgemein bekannt.

Answer 4

Das Problem, das ich mit DI habe, ist das gleiche Problem, das ich mit COM und mit jedem Code habe, der so ähnlich aussieht:

i = GetServiceOrInterfaceOrObject(...)

Das Problem ist, dass ein solches System nicht aus dem Code heraus verstanden werden kann. Es muss irgendwo eine Dokumentation geben, die definiert, welcher Dienst/Schnittstelle/Objekt von Dienst/Schnittstelle/Objekt X angefordert werden kann. Diese Dokumentation muss nicht nur gepflegt werden, sondern auch so einfach wie der Quellcode verfügbar sein.

Wenn das Dokument nicht sehr gut geschrieben ist, ist es oft nicht einfach, die Beziehungen zwischen den Objekten zu erkennen. Manchmal sind die Beziehungen zeitlich begrenzt, was es noch schwieriger macht, sie zu erkennen.

Ich mag das KISS-Prinzip, und ich glaube fest daran, dass man das richtige Werkzeug für die richtige Aufgabe verwenden sollte. Wenn der Nutzen von DI für ein bestimmtes Projekt die Notwendigkeit, verständlichen Code zu schreiben, überwiegt, dann sollte man es verwenden.

Answer 5

Meiner Meinung nach sind die größten Nachteile die Lernkurve (wie Sie betonen) und die Möglichkeit, dass die zusätzliche Abstraktion die Fehlersuche erschwert (was ebenfalls Teil der Lernkurve ist).

DI scheint mir eher für größere, komplexe Systeme geeignet zu sein - bei kleinen, einmaligen Anwendungen kann es dazu führen, dass die Anwendung überarchitektonisch ist, d. h., dass die Architektur mehr Entwicklungszeit in Anspruch nimmt, als sie jemals durch den Wert, den sie bietet, wieder wettmachen kann.