AW: Spring-DI / DelegatedConstructor / Factory für Dummies
Ja, okay, dann geht es aber innerhalb eines einzelnen Autos nicht mehr.
|
AW: Spring-DI / DelegatedConstructor / Factory für Dummies
Zitat:
Ansonsten, wenn Du so initialisierst:
Delphi-Quellcode:
dann ersetzt Du
GlobalContainer.RegisterComponent<TMotor>.Implements<IMotor>;
Delphi-Quellcode:
mit
var
aMotor : TMotor; begin aMotor := TMotor.Create();
Delphi-Quellcode:
In beiden Fällen verweist aMotor auf eine spezielle Instanz.
var
aMotor : IMotor; begin aMotor := ServiceLocator.GetService<IMotor>; |
AW: Spring-DI / DelegatedConstructor / Factory für Dummies
Zitat:
Das ist mein Punkt. Und wenn ich am Ende angelangt bin, ist die ganze schöne Entkoppelung im Eimer. Oder habe ich da jetzt fundamental was nicht verstanden? |
AW: Spring-DI / DelegatedConstructor / Factory für Dummies
Zitat:
Der Fuhrparkleiter fragt das Auto, was es für Sprit will, das fragt den Motor und der muss es schließlich wissen. |
AW: Spring-DI / DelegatedConstructor / Factory für Dummies
Delphi-Quellcode:
So, ich hoffe der Code ist richtig und verständlich.
AutoListe: TList<TAuto>;
type TAuto = class Test1: TMotorTest1; Test2: TMotorTest2; end; IMotor = interface function GetSchraubenAnzahl: Integer; procedure SetSchraubenAnzahl(const Value: Integer); procedure Brumm; property SchraubenAnzahl: Integer read GetSchraubenAnzahl write end; TMotor = class(TInterfacedObject, IMotor) function GetSchraubenAnzahl: Integer; procedure SetSchraubenAnzahl(const Value: Integer); FSchraubenAnzahl: Integer; procedure Brumm; property SchraubenAnzahl: Integer read GetSchraubenAnzahl write SetSchraubenAnzahl; end; TMotorTest1 = class Motor: IMotor; constructor Create; procedure Motortest; end; TMotorTest2 = class Motor: IMotor; constructor Create; procedure Motortest; end; TAuto = class public Test1: TMotorTest1; Test2: TMotorTest2; end; implementation constructor TMotorTest1.Create; begin Motor := ServiceLocator.GetService<IMotor>; end; constructor TMotorTest2.Create; begin Motor := ServiceLocator.GetService<IMotor>; end; initialization GlobalContainer.RegisterComponent<TMotor>.Implements<IMotor>.AsSingleton; Die Schraubenanzahlin Test1 und Test2 sind immer dieselben, was auch richtig ist, da es um denselben Motor geht. Wenn jetzt aber das Auto in der Liste ist, dann ist die Schraubenanzahl bei jedem Auto immer noch dieselbe, aber jedes Auto hat einen anderen Motor mit einer anderen Schraubenanzahl. |
AW: Spring-DI / DelegatedConstructor / Factory für Dummies
Hallo Andreas, vielen Dank nochmal!
Also das mit den Interfaces ist beschlossene Sache! :-) Das werde ich auf jeden Fall angehen und mein Projekt in absehbarer Zeit überarbeiten. Man verbirgt dadurch natürlich wunderbar das ganze interne Klassen-Geraffel und kann sich bei der Verwendung schön auf die "veröffentlichten Schnittstellen" beschränken. Auch ist es egal, um was für Objekte es sich handelt, da nur noch wichtig ist, welche Schnittstellen sie haben. Feine Sache - hätte man ja auch schon mal früher verstehen können. :stupid: Deine Spring-Erklärung klingt eigentlich auch reizvoll, wobei ich noch skeptisch bin, wie flexibel das Ganze ist. Wenn ich einem Auto einen V4-, V6- oder V8- Motor und wahlweise normales Licht oder Kurvenlist anbauen will und es eine Version mit oder ohne Zierleiste gibt, würde man das alles in dem GlobalContainer.RegisterComponent angeben? Klassischer Weise würde ich (nach meinen aktuellen Vorstellungen) ein Auto-Interface erzeugen und dann einen bestimmten Motor, Licht und evtl. Zierleiste zuweisen. Dann wäre das Auto fertig. Das ginge natürlich auch ohne Spring, statt dessen hätte ich eine Unit uWerkstatt, die eine Bestellung erhält und das Auto(-Interface) liefert. Die von Dir (zu Recht) gelobte starke Entkopplung der Komponenten könnte ich durch die Interfaces dann ja auch (fast genau so gut) realisieren. Mein Problem bei meinen Überlegungen stellt sich für mich folgender Maßen: Ich habe z.B. Mannschaften, die Mitglieder enthalten und die wieder die Instanz einer Person. Eine Person hat u.a. einen Status (spielt/bereit/verletzt). In verschiedenen Turnieren sind Spieler enthalten, die eine Personenreferenz (auf die Person eines o.g. Vereinsmitgliedes) haben. Die Spieler können in den unterschiedlichen Turnieren unterschiedliche Punkte erspielen und unterschiedliche Statusse haben. Z.B. kann ich in dem einen Turnier bereits gewonnen haben (ok, ist unrealistisch, aber ja nur ein Beispiel :-)) und im anderen aktuell gerade noch spielen. Es sind also verscheidene Spieler-Objekte, die die gleiche Person referenzieren. Solche Bezüge gibt es viele und in noch komplexerer Form. Diese Bezüge müssen beim Öffnen einer gespeicherten Turnierveranstaltung natürlich auch wieder hergestellt werden. Jetzt stellt sich mir die Frage (egal ob mit Spring oder "nur Interfaces") wie sich solche Dinge sinnvoll handeln lassen. Ich müsste also sogen können:
Delphi-Quellcode:
Die Funktion müsste dann ermitteln, ob es einen solchen Spieler bereits gibt und ihn sonst neu anlegen.
IPlayer := GetPlayerWithPersonId(12345, InTournament(23456));
Bietet Spring dafür Funktionalitäten? Von der Owner-Verschachtelung werde ich mich wohl auf jeden Fall lösen müssen (wie Stevie beschrieben hat), aber damit kann man sicher gut leben. Die Objekte haben dann eben Bezüge, wie sie in einer relationalen DB abgebildet werden, was dann natürlich auch wieder eine Datenspeicherung in einer solchen erleichtern könnte. Es kribbelt jedefalls schon ziemlich in den Fingern... :thumb: |
AW: Spring-DI / DelegatedConstructor / Factory für Dummies
Zitat:
Hinweis 1: Bei Spring brauchen die Interface-Deklarationen immer eine GUID, sonst gehen (intern) sämtliche Supports-Aufrufe nicht. Hinweis 2: Spring verwaltet die Lifetime nur von AsSingleton-Interfaces. D.h. man benötigt bei AsTransient unbedingt eine Basisklasse, welches RefCounting implementiert. (basierend auf Hinweisen von Stefan). |
AW: Spring-DI / DelegatedConstructor / Factory für Dummies
Zitat:
if fuhrpark.eingeteiltesfahrzeug.motor.kraftoffart = diesel then einkaufsabteilung.dieselbestellen; schlechter Stil? Genau das behauptet Demeter. Entkopplung ist Mythos. Als Ausnahme lasse ich in der Tat nur die Entkopplung von GUI/BL gelten. Und auch da nur bedingt. |
AW: Spring-DI / DelegatedConstructor / Factory für Dummies
Zitat:
Zitat:
|
AW: Spring-DI / DelegatedConstructor / Factory für Dummies
Zitat:
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:19 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz