Dependency Injection mit JavaScript

Constructor Injection mit Hilfe von JavaScript-Proxies: Hartcodierte Abhängigkeiten vermeiden und Algorithmen als austauschbare Strategien über einen Inversion of Control-Container bereitstellen. 

Motivation 

High cohesion und low coupling implizieren nicht, daß Assoziationen komplett vermieden werden: Abstraktionen in Programm-Code erfordern konkrete Implementierungen, damit Verträge zwischen Schnittstellen eines Systems erfüllt werden können: Wenn es nichts gibt, was mit einer Schnittstelle konkret kommunizieren kann, dann funktioniert ein Programm auch nicht. 

Die Verwendung von Factorys und Factory-Methoden im gesamten Framework macht es jedoch einfach, Constructor Injection mit Proxys zu realisieren: Die Auswahl eines Konstruktors einer injizierbarer Zielklasse kann automatisiert erfolgen, wenn wir unseren Proxy vor die entsprechenden Methoden der Factories schalten. 

Ein Wrapper-Proxy wird installiert, sobald coon.core.ioc.Container.bind() aufgerufen wird: 

 installProxies () {
        const me = this;

        Ext.Factory = new Proxy(
            Ext.Factory, 
            Ext.create("coon.core.ioc.sencha.resolver.FactoryHandler")
        );

        Ext.create = new Proxy(
            Ext.create, 
            Ext.create("coon.core.ioc.sencha.resolver.CreateHandler")
        );
    },

Für unsere Umsetzung benutzen wir zwei verschiedene Proxy-Handler: 

 Handler für Ext.create 

 Der CreateHandler ist eine Methode um Aufrufe zu Ext.create() abzufangen. Es überprüft das an Ext.create() übergebene Argument wie folgt:  

• Wenn das Argument ein String ist, wird davon ausgegangen, dass es sich um den Namen der Klasse handelt, für die eine Instanz erstellt werden soll 

• Wenn das Argument ein Objekt ist, bedeutet das, dass der Client eine Konfiguration übermittelt, die eine xtype-Property oder eine xclass-Property enthält. In diesem Fall enthält das Objekt auch alle weiteren Informationen, die für die Konfiguration der ZIelinstanz benötigt werden

{
    "xtype": "alias-of-class",
    // or "xclass": "fqn.of.class"
    "cArg1": "foo",
    "cArg2": "bar"  
}

Wie Abbildung 9 zeigt, löst der Handler das classresolved-Event aus und sendet Information, die den Klassennamen und den JavaScript-Prototyp der aufgelösten Klasse beinhalten. 

Handler für Ext.Factory 

 Der FactoryHandler implementiert Traps für  

• ... Eigenschaften, die von einem Client angefordert werden. Hierzu wird intern get() vorgeschaltet und aufgerufen 

• ... jede Methode, die möglicherweise eine Factory-Methode sein könnte. Hierzu wird die vor Funktionen vorgeschaltete apply() Methode aufgerufen. 

Factory-Methoden in Ext JS basieren auf Typen, die über Klassendefinitionen veröffentlicht werden. Aliase werden durchweg in dem Framework verwendet, um bspw. Lazy Instantiation zu realisieren. Diese Aliase verwenden Präfixe, die die Domäne darstellen, zu denen die Repräsentanten funktional einzuordnen sind, z. B. haben Aliase für Ext.data.Store das Präfix store, Ext.app.Controller verwenden das Präfix controller usw. 

Ext.Factory verdrahtet diese Konfigurationen mit den entsprechenden Factory-Methoden, und hier kommt ein vom get()-Handler installierter apply()-Handler ins Spiel: Er funktioniert ähnlich wie der CreateHandler - am Ende löst dieser Proxy das classresolved-Ereignis aus mit entsprechenden Informationen über die Zielklasse. 

if (cls) {
    const className = Ext.ClassManager.getName(cls);
    me.fireEvent("classresolved", me, className, cls);
}

Constructor Proxying 

Es läuft alles auf den ConstructorInjector hinaus: Sobald das classresolved-Ereignis abgeschickt wurde, kann ein entsprechender Observer den ConstructorInjector verwenden, um zu entscheiden, ob Abhängigkeiten in den Konstruktor der Zielklasse injiziert werden sollen: Er prüft, ob die Klasse injizierbar ist, und wenn dies der Fall ist, wird der vorher über den Proxy registrierte Trap für den Konstruktor verwendet. 

Das ganze macht sich die Eigenschaften des Strategy-Pattern zunutze, das es uns ermöglicht, Implementierungsdetails zur Laufzeit auszutauschen. Beachtet werden muß allerdings, dass der ConstructorInjectormit einem Objekt arbeitet, das als Argument an den Konstruktor übergeben wird, und nicht mit einer Liste von Argumenten. Der ConstructorInjector ist also ein Property Injector: Wir benutzen den Namen ConstructorInjector hier, da dadurch der Einsatzzweck verdeutlicht werden soll - und damit auch das o.a. Wann. 

Der Trap für den Konstruktor untersucht die Zielklasse nach allen erforderlichen Abhängigkeiten (definiert als Metainformationen in der vorher vereinbarten required-Property) und verwendet dann den Dependency Resolver, um aus den Bindings, die zuvor mit coon.core.io.Container.bind() registriert wurden, eine Zielinstanz mit allen benötigten Abhängigkeiten zu erstellen. 

Anmerkungen 

Das Repository für coon.js und die IoC-Container-Implementierung befindet sich auf Github. Es wird bereits in der neuesten Version von conjoon verwendet, unserer Referenzimplementierung für npm-basierte Sencha Ext JS Projekte.  

Der Artikel wurde ursprünglich in Englisch veröffentlicht und ist hier zu finden.