Was ist eine gute Metapher für Dependency Injection?

Question

Eine Metapher, die ich bei der Programmierung von Nicht-DI-Systemen festhielt, ist "eine Person, die mit ihren Spielzeugen spielt". Eine Person ist ein Objekt und die Spielzeuge der Person sind alles, was das Objekt erzeugt, speichert, initialisiert und manipuliert. Die Spielzeuge können Ereignisse auslösen, wenn sie einen bestimmten Zustand erreichen, aber sie wissen nichts über die Person, die sie benutzt; Sie sind nur kleine schwarze Kästchen mit Steuerschaltern, die ihre Schnittstellen ausmachen. Die Person kann auf Ereignisse von den Spielzeugen hören und reagieren, indem sie ihre Schnittstellen manipuliert. Die Person kann mit ihren Spielzeugen machen, was immer sie will, aber sie/er sollte sich wahrscheinlich nicht mit ihren Innereien einmischen, weil sie brechen könnten.

Die Verwüstung, die DI meiner Metapher zufügt, ist, dass es die Spielzeuge in bewusste Wesen verwandelt, die ihren Besitzer, die Person, die sie benutzt, kennen. Die Spielzeuge können diese Person manipulieren, aber die Person weiß nichts davon, wie sie arbeitet und kümmert es nicht einmal. Die Person besitzt nur die Spielzeuge und erwartet, dass die Spielzeuge ihn zur Zufriedenheit des Spielers manipulieren.

WTF ?? Das hört sich schrecklich an !!
Was ist eine gute mentale Metapher, die sie verwendet haben, um darüber nachzudenken, wie DI-Systeme funktionieren?

Answer 1

Die SOLID motivational images sind eine gute Quelle.

Answer 2

Die Spielzeuge sind nicht bei Bewusstsein. Sie lassen die Person einfach Schnurstücke an Haken binden, und wenn bestimmte Dinge passieren, drehen sich die Haken und die Schnur wird angezogen, so dass die Person weiß, dass etwas passiert ist.

Answer 3

Aus meiner Sicht ist der Unterschied zwischen DI und Nicht-DI in Bezug auf Ihre Metapher mit Nicht-DI-Systemen, jede Person macht ihr eigenes Spielzeug - sie müssen wissen, wie man sie herstellt und sie können nur die Spielzeuge verwenden Sie machen. Bei DI verwendet die Person die Spielsachen, die ihnen gegeben werden. Sie wissen nicht, wie man sie herstellt, aber sie können mit jedem Spielzeug spielen, solange sie wissen, wie sich das Spielzeug verhält.

Answer 4

Denken Sie einen Gentleman und seinen Butler. Der Butler (das DI-Framework) stellt dem Gentleman alle Dienste (externe Abhängigkeiten) zur Verfügung, die er auf Nachfrage benötigt (und einige, wie den Morgenkaffee, nach der "Initialisierung" :-)); der Gentleman (deine Klasse) konsumiert nur die Dienste und kümmert sich nicht darum, woher sie kommen, solange sie seine Anforderungen erfüllen (bestimmte Schnittstellen implementieren).

Oder wenn Sie es näher an Ihre Metapher machen wollen, ist Ihre Klasse das Kind, das DI-Framework ist die Mutter, und die Spielzeuge sind die anderen Komponenten. Dem Kind ist es egal, woher die Spielsachen kommen, solange sie mit ihnen spielen kann, wie sie will.

Answer 5

Es geht um Samurais und Waffen. Versuchen Sie es mit ninject: http://ninject.org/. Gehe zum "Visit the Dojo" -Zeichen für eine interessante Metapher. Nicht sicher, ob das gemeint ist, aber es ist trotzdem kreativ.

Answer 6

Legos.

Denken Sie an einen Lego-Block als eine Softwarekomponente, die eine oder mehrere Schnittstellen (die kleinen Höcker an der Spitze) verfügbar macht und einen oder mehrere Setter oder Konstruktorargumente (die Löcher auf der Unterseite) hat.

Wenn Sie eine Box mit Legos kaufen, werden die Blöcke nicht vormontiert (fest verdrahtet) geliefert. Sie sind unabhängige Komponenten. Dann assemblieren Sie sie (verdrahten Sie sie), indem Sie Schnittstellen (Bumps) mit Setter/Konstruktoren (Löchern) verbinden. Jeder Block weiß nichts über die anderen Blöcke direkt. Es ist etwas anderes als der Block erforderlich, um sie zusammenzusetzen - das ist Sie (oder main() oder eine Spring-Konfigurationsdatei usw.).

Ich weiß ... bricht dies ein wenig nach unten, weil Legos weitgehend eine einheitliche Schnittstelle haben - aber es funktioniert für mich :-)

Answer 7

I Computersystem verwenden.Sie haben einen Systemblock, und Sie (ein DI) verbinden einen Monitor, eine Tastatur und eine Maus mit ihm. Der Systemblock weiß nur, dass ein Monitor ein DVI-Gerät ist, kümmert sich aber nicht darum, welcher Monitor es genau ist. Es weiß, wie man USB-Maus benutzt, aber weiß nicht oder interessiert sich nicht dafür, ob es sich um eine optische oder eine Kugelmaus handelt.

Sie - das DI-Framework.
Systemblock - wird das System bedient.
Monitor/Maus/Tastatur - Dienste, die DI (Sie) dem Systemblock zur Verfügung stellt.

Answer 8

Eine DI-Metapher, die mir gesagt wurde, war die eines CD-Players. Dem Spieler ist es egal, welche CD du einlegst; Jede CD, die Sie in den Player einlegen, bietet jedoch unterschiedliche Funktionen, je nachdem, was der Player benötigt.