Gibt es harte Daten über den Wert von Inversion of Control oder Abhängigkeitsinjektion?

Question

Ich habe viel über IoC und DI gelesen, aber ich bin nicht wirklich davon überzeugt, dass Sie in den meisten Situationen viel davon bekommen.

Wenn Sie Code schreiben, der steckbare Komponenten benötigt, dann sehe ich ja den Wert. Aber wenn das nicht der Fall ist, frage ich mich, ob das Ändern einer Abhängigkeit von einer Klasse zu einer Schnittstelle wirklich etwas anderes bringt als das Tippen.

In einigen Fällen kann ich sehen, wo IoC und DI mit Mocking helfen, aber wenn Sie nicht Mocking oder TDD verwenden, was ist der Wert? Ist das ein Fall von YAGNI?

Answer 1

Ich bezweifle, dass Sie irgendwelche harten Daten darüber haben, also werde ich einige Gedanken dazu hinzufügen.

Zuerst verwenden Sie nicht DI (oder andere SOLID-Prinzipien), weil es Ihnen hilft, TDD zu tun. Andersherum macht man TDD, weil es dir beim Design hilft - was normalerweise bedeutet, dass du Code bekommst, der diesen Prinzipien folgt.

Diskutieren, warum die Verwendung von Schnittstellen ist eine andere Sache, siehe: https://stackoverflow.com/questions/667139/what-is-the-purpose-of-interfaces.

Ich gehe davon aus, dass Sie zustimmen, dass Ihre Klassen viele verschiedene Dinge haben, was zu unordentlichem Code führt.Daher gehe ich davon aus, dass Sie sich bereits für SRP entscheiden.

Da Sie verschiedene Klassen haben, die bestimmte Dinge tun, benötigen Sie eine Möglichkeit, sie in Beziehung zu setzen. Wenn Sie sie innerhalb der Klassen (d. H. Den Konstruktoren) beziehen, erhalten Sie viel Code, der bestimmte Versionen der Klassen verwendet. Dies bedeutet, dass Änderungen am System schwierig sein werden.

Sie müssen das System ändern, das ist eine Tatsache der Softwareentwicklung. Sie können YAGNI anrufen, um bestimmte zusätzliche Funktionen nicht hinzuzufügen, aber Sie müssen das System nicht ändern. In meinem Fall ist das etwas sehr Wichtiges, da ich wöchentliche Sprints mache.

Ich verwende ein DI-Framework, wo die Konfiguration über Code erfolgt. Mit einer wirklich kleinen Code-Konfiguration verbinden Sie viele verschiedene Beziehungen. Also, wenn Sie die Diskussion über Schnittstellen vs. konkrete Klassen wegnehmen, sparen Sie tatsächlich das Tippen nicht umgekehrt. Auch für die Fälle befindet sich eine konkrete Klasse im Konstruktor, sie hängt sich automatisch an (ich muss das nicht konfigurieren) und baut die restlichen Beziehungen auf. Es erlaubt mir auch, die Lebensdauer einiger Objekte zu steuern, insbesondere kann ich ein Objekt als Singleton konfigurieren und es gibt immer eine einzige Instanz.

Beachten Sie auch, dass die Verwendung dieser Verfahren nicht mehr Aufwand verursacht. Wenn man sie zum ersten Mal benutzt, verursacht dies den Overhead (wegen des Lernprozesses + in einigen Fällen ist die Änderung der Denkweise nötig).

Fazit: Sie müssen nicht alle diese Konstruktor Anrufe überall platzieren, um schneller zu gehen.

Answer 2

Die wichtigsten Vorteile von DI sind nicht unbedingt auf die Verwendung von Schnittstellen zurückzuführen. Sie müssen nicht unbedingt Schnittstellen verwenden, um vorteilhafte Auswirkungen der Abhängigkeitsinjektion zu haben. Wenn es nur eine Implementierung gibt, können Sie diese wahrscheinlich direkt injizieren, und Sie können eine Mischung aus Klassen und Schnittstellen verwenden.

Sie erhalten immer noch lose Kopplung, und ziemlich viele Entwicklungsumgebungen können Sie diese Schnittstelle bei Bedarf mit ein paar Tasten drücken.

Harte Daten über den Wert der losen Kopplung kann ich nicht geben, aber es war eine Vision in Lehrbüchern, solange ich mich erinnern kann. Jetzt ist es echt.

DI-Frameworks bieten Ihnen auch einige erstaunliche Funktionen, wenn es um hierarchische Konstruktion großer Strukturen geht. Anstatt nach dem schlanksten DI-Framework zu suchen, würde ich empfehlen, nach einem voll ausgestatteten zu suchen. Weniger ist nicht immer mehr, zumindest wenn es darum geht, über neue Wege der Programmierung zu lernen. Dann können Sie für weniger gehen.

Answer 3

Neben der Prüfung lohnt sich auch die losen Kopplung.

Ich habe an Komponenten für ein eingebettetes Java-System gearbeitet, das nach dem Start eine feste Konfiguration von Objekten hatte (etwa 50 meist unterschiedliche Objekte).

Die erste Komponente war Legacy-Code ohne Abhängigkeitsinjektion, und die Unterobjekte wurden überall erstellt. Jetzt geschah es einige Male, dass für einige Modifikationen etwas Code benötigt wurde, um mit einem Objekt zu sprechen, das nur drei Konstrukteure entfernt verfügbar war. Also was können Sie tun, aber fügen Sie dem Konstruktor einen anderen Parameter hinzu und übergeben Sie ihn, oder speichern Sie ihn in einem Feld, um ihn später weiterzugeben. Auf lange Sicht wurden die Dinge noch verwirrender als sie bereits waren.

Die zweite Komponente, die ich von Grund auf neu entwickelte, und verwendete Dependency-Injektion (ohne es zu der Zeit zu wissen). Das heißt, ich hatte eine Fabrik, die alle Objekte konstruierte und dann auf der Notwendigkeit, zu wissen, injizierte. Es war einfach, eine weitere Abhängigkeit hinzuzufügen, fügen Sie sie einfach der Factory und dem Objektkonstruktor hinzu (oder fügen Sie einen Setter hinzu, um Schleifen zu vermeiden). Kein nicht verwandter Code musste berührt werden.