Dann erschließt sich mir nicht der Sinn eines DelegatedConstructor (ich kann doch auch später einem Objekt ein anderes als Property zuweisen).
Ich beziehe mich einmal auf obiges Beispiel.
Spring ruft beim (internen) Instantiieren von TMyDatabase den Konstruktor ohne Parameter auf. Wenn das nicht geht, muss man bei
GlobalContainer.RegisterComponent<TMyDatabase>.Implements<IDatabase>.AsSingletonPerThread
noch Spring mitteilen, welcher Konstruktor verwendet werden soll. Hier kommt der DelegatedConstructor in's Spiel:
Delphi-Quellcode:
GlobalContainer.RegisterComponent<TMyDatabase>.Implements<IDatabase>.AsSingletonPerThread.DelegateTo(
function: TMyDatabase
begin
Result := TMyDatabase.Create(nil);
end
)
Ansonsten ist das Spring-Framework mehr als nur ein DI-Container. Der ist aber der wichtigste Teil. Du weißt ja, dass DI (Dependency Injection) dazu führt, praktisch keine Objekte, die komplexer sind als etwa TStringList, mehr in der Klasse selbst zu erzeugen. Stattdessen bekommt die Klasse die notwendigen Instanzen der erforderlichen Klassen von "außen" zugewiesen.
Zitat:
Nicht das Auto prüft vor Abfahrt, ob die Räder montiert sind, sondern bei der Montage und vor der Abfahrt aus der Fabrik wird dem Auto alles notwendige an- und eingebaut.
Auch ohne die Notwendigkeit, sein Programm ohnehin zu flexibilisieren, gibt es immer genau einen Anwendungsfall für ein solches Vorgehen: der Test. Da schiebe ich (von außen) meiner Klasse alle die Szenarien unter (in Form von Mock-Instanzen), für die sie funktionieren soll.
So gesehen führt DI zu testbaren Code führt zu Clean-Code führt in den Programmierer-Himmel.
