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

Dies ist eher ein Erbsenzähler. Aber einer der Nachteile von Dependency Injection ist, dass es für Entwicklungswerkzeuge etwas schwieriger ist, den Code zu verstehen und zu navigieren.

Wenn Sie im Code bei gedrückter Strg-Taste oder mit der Befehlstaste auf einen Methodenaufruf klicken, werden Sie zur Methodendeklaration einer Schnittstelle und nicht zur konkreten Implementierung geführt.

Dies ist eher ein Nachteil von lose gekoppeltem Code (Code, der über Schnittstellen entwickelt wird) und gilt auch dann, wenn Sie keine Dependency Injection verwenden (d.h. auch wenn Sie einfach nur Factories verwenden). Aber das Aufkommen von Dependency Injection hat lose gekoppelten Code erst so richtig populär gemacht, deshalb wollte ich es erwähnen.

Außerdem überwiegen die Vorteile von lose gekoppeltem Code bei weitem, daher nenne ich es einen Nitpick. Allerdings habe ich lange genug gearbeitet, um zu wissen, dass dies die Art von Rückschlag ist, die man bekommen kann, wenn man versucht, Dependency Injection einzuführen.

Ich wage zu behaupten, dass Sie für jeden "Nachteil", den Sie für Dependency Injection finden können, viele Vorteile finden werden, die ihn bei weitem überwiegen.

Answer 2

Konstruktorbasiert Die Injektion von Abhängigkeiten (ohne die Hilfe von magischen "Frameworks") ist eine saubere und vorteilhafte Methode, OO-Code zu strukturieren. In den besten Codebasen, die ich im Laufe der Jahre mit anderen ehemaligen Kollegen von Martin Fowler gesehen habe, habe ich festgestellt, dass die meisten guten Klassen, die auf diese Weise geschrieben wurden, am Ende eine einzige doSomething Methode.

Der größte Nachteil ist jedoch, dass die Motivation, OO-Code zu schreiben, schnell schwindet, sobald man erkennt, dass es sich nur um eine umständliche, langwierige OO-Methode handelt, bei der Closures als Klassen geschrieben werden, um die Vorteile der funktionalen Programmierung zu nutzen.

Answer 3

Ich finde, dass Konstruktorinjektion zu großen, hässlichen Konstruktoren führen kann (und ich verwende sie in meiner gesamten Codebasis - vielleicht sind meine Objekte zu granular). Auch, manchmal mit Konstruktor-Injektion ich am Ende mit schrecklichen zirkulären Abhängigkeiten (obwohl dies sehr selten ist), so können Sie finden sich mit einer Art von fertigen Zustand Lebenszyklus mit mehreren Runden der Abhängigkeit Injektion in einem komplexeren System haben.

Ich bevorzuge jedoch Construtor Injection gegenüber Setter Injection, weil ich, sobald mein Objekt konstruiert ist, zweifelsfrei weiß, in welchem Zustand es sich befindet, egal ob es sich in einer Unit-Test-Umgebung befindet oder in einem IOC-Container geladen ist. Damit ist auf Umwegen gesagt, was meiner Meinung nach der größte Nachteil von Setter-Injection ist.

(nebenbei bemerkt, finde ich das ganze Thema ziemlich "religiös", aber das hängt vom Grad des technischen Eifers in Ihrem Entwicklerteam ab).

Answer 4

Wenn Sie DI ohne einen IOC-Container verwenden, besteht der größte Nachteil darin, dass Sie schnell sehen, wie viele Abhängigkeiten Ihr Code tatsächlich hat und wie eng alles gekoppelt ist. ("Aber ich dachte, das wäre ein gutes Design!") Die natürliche Entwicklung ist der Übergang zu einem IOC-Container, der ein wenig Zeit zum Erlernen und Implementieren benötigt (nicht annähernd so schlimm wie die Lernkurve bei WPF, aber auch nicht kostenlos). Der letzte Nachteil ist, dass einige Entwickler anfangen werden, echte Unit-Tests zu schreiben, und es wird einige Zeit dauern, bis sie es herausfinden. Entwickler, die zuvor etwas in einem halben Tag erstellen konnten, werden plötzlich zwei Tage damit verbringen, herauszufinden, wie sie alle ihre Abhängigkeiten abbilden können.

Ähnlich wie bei der Antwort von Mark Seemann geht es im Endeffekt darum, dass man Zeit damit verbringt, ein besserer Entwickler zu werden, anstatt Codestücke zusammenzuhacken und sie durch die Tür in die Produktion zu werfen. Was würde Ihr Unternehmen lieber haben? Das können nur Sie beantworten.

Answer 5

DI ist eine Technik oder ein Muster und nicht an einen Rahmen gebunden. Sie können Ihre Abhängigkeiten manuell verdrahten. DI hilft Ihnen bei SR (Single responsibility) und SoC (separation of concerns). DI führt zu einem besseren Design. Aus meiner Sicht und Erfahrung es gibt keine Nachteile . Wie bei jedem anderen Muster kann man es falsch machen oder missbrauchen (was aber im Fall von DI ziemlich schwer ist).

Wenn Sie DI als Prinzip in eine Legacy-Anwendung einführen, indem Sie ein Framework verwenden, ist der größte Fehler, den Sie machen können, es als Service-Locater zu missbrauchen. DI+Framework selbst ist großartig und hat die Dinge überall, wo ich es gesehen habe, besser gemacht! Aus organisatorischer Sicht gibt es die üblichen Probleme mit jedem neuen Prozess, jeder neuen Technik, jedem neuen Muster, ...:

• Sie müssen Ihr Team schulen
• Sie müssen Ihre Bewerbung ändern (was auch Risiken beinhaltet)

Im Allgemeinen müssen Sie Zeit und Geld investieren Abgesehen davon gibt es keine Nachteile, wirklich nicht!