Tag Archives for Dependency Injection

AngularJS 1.2.14 (ff): $scope.$watchCollection

$watchCollection würde man intuitiv so verwenden (Quelle):

Das funktioniert aber nicht. Korrekt wäre ein großer String (Quelle):

Darüber hinaus gibt es einen Bug in v1.2.14 (und in gewissen Szenarien auch darüber hinaus), bei dem newValues[i] immer gleich oldValues[i] ist. Der Fix dafür hat aber ebenfalls einen Bug: Die Dependecies werden nicht korrekt injected. Folgende Änderungen waren nötig:

Ein Pull Request ist nicht möglich, aber vllt zieht sich der Autor das auf meinen Kommentar hin.

Schlussendlich: Nicht vergessen, die Decorators in die App zu injecten:

Spring: Dependency Injection in statische Variablen

Es gibt n+1 Artikel, warum das architektonisch keinen Sinn ergeben würde – aber wenn man das trotzdem möchte, findet sich hier die Lösung (leicht abgewandelt, zB ist der Setter privat), die keine Konstruktor-Parameter erfordert:

PS: Der Setter wird nur beim Startup aufgerufen, und nicht mit jedem Bean, insofern entsteht dadurch kein Performance-Issue.

PPS, Achtung: Dieser Kommentar hat recht, deshalb Vorsicht! Ggf. sollte das Feld transient sein

ungetestete Alternative

via:

AS3: Optionales Injecten mit Robotlegs/SwiftSuspenders

Injects sind in Robotlegs 1.x/SwiftSuspenders 1.x erst mal verbindlich, so wie ich eine entsprechende Aussage von Till Schneidereit verstehe. Ein [Inject] führt dann zu einer Fehlermeldung:

Error: Injector is missing a rule to handle injection into property “myProperty” of object “[object MyClass]”. Target dependency: “com.acme.some.package::MyInjectType”, named “”

Der dort verlinkte Custom Build (Downloadübersicht siehe hier) enthält SwiftSuspenders 2, und das erlaubt optionale Injects. In meinem Test funktioniert das übrigens ohne ein “(optional=true)”, wie im oben verlinkten Thread vorgeschlagen – der Inject ist einfach null.

Frage zu Command Pattern und “Zwillingsklassen” [BEANTWORTET]

Was ich mir eigentlich wünsche, ist Mehrfachvererbung: Ich habe verschiedene Klassen A, B, C, und die sollen die Funktionen x(), y(), z() in unterschiedlichen Kombinationen anbieten. Klasse A kann x() und y(), brauch aber z() nicht zu können; Klasse B kann alle drei, und Klasse C nur x().

Mehrfachvererbung mag theoretisch zu Problemen führen, praktisch ist es aber (auch deshalb) so, dass z.B. AS3 sie nicht unterstützt. Deswegen spare ich mir diesen Absatz mal 😉

Auf Wikipedia finde ich als Alternative das Konzept der Zwillingsklasse, das mir neu war. Mir stellt sich dabei aber dieselbe Frage wie beim Command Pattern:

  • Bei der Zwillingsklasse wäre z.B. Klasse A ein Wrapper für zwei (oder mehr) Instanzen komplexer Klassen der Typen, die auf Grund fehlender Mehrfachvererbung nicht gleichzeitig beerbt werden können. Diese Instanzen bieten hier im Beispiel jeweils die Funktionen x() und y().
  • Das Command Pattern lagert die eigentliche Funktionalität von x(), y() und z() in so genannte Commands aus. In so einem Command ist auch jeweils nix anderes drin als diese eine Funktionalität (und ggf. alles, was dazu gehört); im Beispiel hätte A also je ein Command für x() und eines für y()

Das Command Pattern klingt für meine Begriffe erst mal besser, da sich das im Wiki-Artikel zu Zwillingsklassen beschriebene Problem der Redundanz nicht stellt. Aber, und das ist meine Frage zu beiden Ansätzen: Oft möchte ich in den Funktionen auf (private) Attribute der jeweiligen Klasse zugreifen. Wie soll das in den Ansätzen (schön) funktionieren?

Mein Ansatz wäre: Dem Command eine Referenz auf sich selbst mitgeben, und gleichzeitig ein Interface implementieren, um die Abhängigkeit von Command zum Parent nicht zu groß werden zu lassen. Aber schön ist was anderes… private Attribute freigeben, nur damit eigentlich in der Klasse zu verortende Funktionalität darauf zugreifen kann?? Gibt es einen anderen Ansatz? Falls nicht: Wie strukturiert man sowas? Je ein Package mit Command und “zugehörigem” Interface für zukünftige Parents??

Bis dahin schreibe ich die Funktionen halt doppelt.

ANTWORT (vorerst?): Robotlegs, bzw. Dependency Injection. Dort (und vermutlich auch überall sonst, wenn man etwas mehr Ahnung von Entwurfsmustern hat als ich) kann ich jede Art von Daten in ein Command “injizieren”, also insbesondere die von mir gewünschten privaten Daten (Models, …). Bzw. andersherum: Ich deklariere im Command meine “Dependencies”, meine Abhängigkeiten. Wie sagte Christian so schön: “Woher die Daten kommen, ist der Klasse [dem Command] egal.” Mit einem Framework wie Robotlegs ist es aber tatsächlich auch dem Entwickler egal; man deklariert dann nämlich nur noch, welche (ggf. singuläre) Instanz man in das Command injizieren möchte, das macht insgesamt zweieinhalb Zeilen Code. Ohne sich drum kümmern zu müssen, wie die Daten nun von A nach B kommen, kann ich im Command auf die gewünschten Daten zugreifen. Thumbs up.