Warum integrieren Sprachen Dependency Injection nicht in ihren Kern (auf der untersten Ebene: Kompilierung vielleicht), da Abhängigkeiten die Wurzel allen Übels in der Komplexitätstheorie sind? Dies würde die Verwendung von Frameworks vermeiden.
Ich ziele eher auf kompilierte Sprachen.
Meine Frage ähnelt der Eingabe von Duck, die kürzlich mit Dynamics in .NET eingeführt wurde. Warum nicht etwas Ähnliches in der Zukunft für DI?
Update: Hey Jungs das Thema scheint von Interesse zu sein, alle Wähler für die Wiedereröffnung es:)
Ich persönlich kann den Nutzen davon sehen. Zum Beispiel schreibe ich ständig Code wie diesen:
%Vor%Wäre es nicht schön, es folgendermaßen schreiben zu können:
%Vor%Ich wünschte, ich könnte einfach alle Rohrleitungen weglassen, indem ich meine Abhängigkeitsfelder deklariere und sie in meinem Konstruktor erstelle.
AKTUALISIEREN
Unsere Gebete könnten gehört worden sein. Das C # -Team könnte "prägnant hinzufügen Syntax für Klassendefinitionen "wie us-Eigenschaften, die" direkt aus dem Konstruktor "in C # 6.0 deklariert werden können. Hoffen wir, dass eine solche Funktion das Licht macht.
Also Ihre Kernfrage "Warum integrieren Sprachen nicht im Kern Dependency Injection?", tun sie. Scala und F # machen das schon viel einfacher und C # wird hoffentlich folgen.
In der Zwischenzeit habe ich versucht, dieses Hindernis zu überwinden, indem ich eine T4-Vorlage schreibe, die den Konstruktor für Sie in einer Teilklasse generiert , aber nachdem ich einige Wochen in einer Anwendung damit gearbeitet habe, hat es wirklich nicht wie erwartet funktioniert.
Wie Grodon in den Kommentaren sagt: Funktions- / Methodenparameter sind Dependency Injection - und praktisch alle Sprachen unterstützen diese auf den niedrigsten Ebenen.
DI-Frameworks sind normalerweise auf Serverumgebungen zugeschnitten. Sprachmechanismen wären dafür einfach die falsche Abstraktionsebene.
Sie tun es tatsächlich, indem Sie Parameter an Methoden / Konstruktoren / Funktionen übergeben - und das ist so ziemlich alles, was DI-Frameworks tun, ist nur eine raffinierte Art, Parameterwerte anzugeben.
Eine interessantere Frage wäre, wie man die Injektion von Abhängigkeit auf einer Sprachebene erzwingt. Das Verbot von static state ist wahrscheinlich ein guter Anfang (wie Neuspeak).
Das ist von Natur aus ein fehlerhafter Ansatz. Idealerweise sollten Sprachen so schlank wie möglich sein, aber mächtig genug sein, um beliebige Abstraktionen auf Sprachenebene einzuführen (denken Sie an LISP und Metaprogrammierung). Wenn nicht, wo ziehst du die Grenze zwischen dem, was enthalten sein soll und was du weglassen sollst?
Was die Einführung der Unterstützung auf Übersetzungsebene für DI angeht, ist das einfach unmöglich. Ihre Anwendung verwendet möglicherweise dynamisch verknüpfte Bibliotheken, die zum Zeitpunkt der Kompilierung möglicherweise nicht bekannt sind. Denk an Plugins.
Wenn eine Sprache flexibel genug ist, kann simulieren DI. Java und C # sind eindeutig nicht, aber funktionale oder hybride Sprachen sind oft. Z.B. In Haskell können Sie eine "Reader-Monade" verwenden, um eine "Umgebung" zu halten, ohne dass Ihr Code verunreinigt wird, oder vielleicht könnten Sie Klassen verwenden. Scala hat Mixin-Komposition und implizite Objekte, die beide dafür genutzt werden könnten. Ich würde also schlussfolgern, dass eine Sprache, die wirklich braucht DI, nur über angemessene und mächtige Abstraktionsmechanismen verfügt.
Tags und Links java c# dependency-injection frameworks inversion-of-control