Was sind die Nachteile bei der Verwendung von Dependency Injection?

Question

Ich versuche, DI als Muster hier bei der Arbeit einzuführen, und einer unserer leitenden Entwickler würde es gerne wissen: Was - wenn überhaupt - sind die Nachteile zur Verwendung des Dependency Injection-Musters?

Bitte beachten Sie, dass es mir hier um eine - möglichst vollständige - Liste geht, nicht um eine subjektive Diskussion zu diesem Thema.

---

Klärung : Ich spreche über die Dependency Injection Muster (siehe dieser Artikel von Martin Fowler), no ein bestimmtes Framework, sei es XML-basiert (wie Spring) oder codebasiert (wie Guice), oder "selbstgesteuert".

---

bearbeiten : Einige großartige weitere Diskussionen / Tiraden / Debatten /r/programmierung hier.

Answer 1

Lesbarkeit des Codes. Da die Abhängigkeiten in XML-Dateien versteckt sind, ist der Codefluss nicht leicht zu erkennen.

Answer 2

Es scheint, dass die vermeintlichen Vorteile einer statisch typisierten Sprache deutlich abnehmen, wenn man ständig Techniken einsetzt, um die statische Typisierung zu umgehen. Eine große Java-Firma, bei der ich gerade ein Interview geführt habe, hat ihre Build-Abhängigkeiten mit statischer Code-Analyse abgebildet... die alle Spring-Dateien analysieren musste, um effektiv zu sein.

Answer 3

Zwei Dinge:

• Sie erfordern eine zusätzliche Werkzeugunterstützung, um zu überprüfen, ob die Konfiguration gültig ist.

IntelliJ (kommerzielle Version) unterstützt zum Beispiel die Überprüfung der Gültigkeit einer Spring-Konfiguration und zeigt Fehler wie Typverletzungen in der Konfiguration an. Ohne diese Art von Werkzeugunterstützung können Sie nicht überprüfen, ob die Konfiguration gültig ist, bevor Sie Tests ausführen.

Das ist ein Grund, warum das "Cake"-Muster (wie es in der Scala-Gemeinde bekannt ist) eine gute Idee ist: Die Verdrahtung zwischen den Komponenten kann vom Type Checker überprüft werden. Diesen Vorteil haben Sie bei Annotationen oder XML nicht.

• Das macht die globale statische Analyse von Programmen sehr schwierig.

Frameworks wie Spring oder Guice machen es schwierig, statisch zu bestimmen, wie der vom Container erstellte Objektgraph aussehen wird. Obwohl sie beim Start des Containers einen Objektgraphen erstellen, bieten sie keine nützlichen APIs, die den Objektgraphen beschreiben, der erstellt werden /würde/.

Answer 4

Dies kann die Startzeit der Anwendung verlängern, da der IoC-Container die Abhängigkeiten in angemessener Weise auflösen sollte und dies manchmal mehrere Iterationen erfordert.