Design von Interface vs IoC/DI

Question

Seit langem entwerfe ich Anwendungen mit Polymorphismus auf Basis von Interface/Inheritance, um lose gekoppelten Code zu erhalten. Soweit ich sehen kann (bisher), stellen DI-Frameworks/IoC lediglich Werkzeuge zur Verfügung, um dies "einfacher" zu machen, jedoch scheint das zusätzliche Abstraktionsniveau überflüssig zu sein und kostet Sie zusätzlichen Overhead.

Der einzige Grund, den ich denken kann, ist, wenn ein großes Team bereits ein bestimmtes DI/IoC-Framework kennt, dann kann jeder auf der gleichen Seite sein.

Aus meiner Sicht scheint DI das gleiche zu tun wie Design by Interface, ich hoffe, dass es mehr als das gibt, könnte mir jemand erklären, warum die Verwendung eines DI/IoC-Frameworks eine bessere Strategie ist?

Ich hoffe wirklich, ich habe es falsch über DI/IoC.

Answer 1

Zum einen können Sie this required reading und bearbeiten in irgendwelchen fehlenden Punkte von dort lesen ...

Wenn Sie DI Container ein erwar) sein außerordentlich komplexe Tiere oder b) ein ganz neues Design-Paradigma, ich rechne Du reagierst auf die normale defensive Art und Weise, wie man einem übertriebenen Konzept begegnet.

Während man viel Aufwand in die Verwendung von DI-Containern auf allen Arten von obskuren Wegen investieren kann, und da ist viel Kraft dort mit Überlappungen mit AOP etc., ist der typische Sweet-Spot für die automatische Verdrahtung von Abhängigkeiten ohne alle "das ganze Team muss etwas verstehen" oder "Overhead" (meinst du konzeptionell oder perf? Wenn letzteres, hast du den Einfluss in einer tatsächlichen App gemessen?).

Aber verstehen Sie dies: - die Freiheit und Fokus auf sauberes Design durch die Verringerung der Reibung und erhöhte Formbarkeit resultierend davon, dass Sie eine Menge Standardcode wegspülen (und die Notwendigkeit, jig ändern, wenn sich Dinge ändern) IOC-Container sind für mich ein kritischer Teil eines Entwicklungsökosystems. Während sie hier und da nur ein paar new s machen, sind ihre Auswirkungen nicht im Verhältnis zu der tatsächlichen (kleinen) Arbeit, die sie machen.

Ob sie sich von der normalen Schnittstellen-basierten Programmierung und guten Designprinzipien unterscheiden, würde ich sie als etwas viel kleiner betrachten - ein Werkzeug, das nur einen der SOLID principles ermöglicht.

Answer 2

Nein, DI/IoC ist nicht das Gleiche wie das Entwerfen von Schnittstellen.

Ein DI/IoC-Motor ist wirklich nur eine große Instanz Fabrik. Es erspart Ihnen das Schreiben und Verwalten Ihrer eigenen.

Die Vorteile sind weniger Wartung (Sie müssen es nicht schreiben) und eine größere Zielgruppe, um Fehler zu finden und zu melden. Wenn das Team, das die DI/IoC-Engine geschrieben hat, besser ist als Sie und Ihr Team, können Sie qualitativ hochwertigere Software verwenden. Und wenn Sie sich für eine Lösung entscheiden, die sich in einer größeren Verbreitung befindet als Ihre selbstgewonnene Lösung, besteht die Chance, dass Außenstehende wissen, wie sie diese verwenden, indem sie Bücher lesen, die weit verbreitet sind. Die Mitarbeiter Ihres Teams werden ihre Lebensläufe verbessern, indem sie mit einem bekannten Framework vertraut sind und Erfahrungen sammeln.

Ich würde Sie ermutigen, weiterhin zu Schnittstellen zu entwerfen, aber es gibt mehr zu DI als das.