Die "Objekte" sind von TComponent abgeleitet (damit sie einen Owner haben und ich sie ggf. auch in der
IDE einrichten kann) und enthalten Daten und BL.
Will ich in einem Spiel ermitteln, ob es sich in einem Turnier befindet, nutze ich eine lokale Variable und eine externe (in einer gesonderten
Unit abgelegten) Funktion.
Delphi-Quellcode:
function OwnerTournament(C: TComponent): TodTournament;
begin
Result := nil;
if C is TodTournament then
Result := (C as TodTournament)
else if C.Owner <> nil then
Result := OwnerTournament(C.Owner);
end;
Im Spiel dann etwa:
Delphi-Quellcode:
procedure TodGame.Calc;
var
MyTournament: TodTournament;
begin
...
MyTournament := OwnerTournament(Self);
if Assigned(MyTournament) then
MyTournament.Calc;
...
end;
Auf diese Weise kennt ein Spiel zwar nicht unmittelbar sein Turnier, kann dieses aber bei Bedarf ermitteln und dort z.B. die Ermittlung der Platzierungen veranlassen (das sollte ja erfolgen, wenn ein Spiel neue Ergebnisse hat).
Für SOOO schlecht halte ich dieses Konstrukt eigentlich nicht.
Deinen letzten Satz kann ich nicht im Detail nachvollziehen. Sollte man BL-Klassen und Datenklassen getrennt definieren und erzeugen? Wo liegt der Vorteil?
Im Moment kann der User ein neues Projekt anlegen, was einem TodTournamentEvent.Create() entspricht. Einige SubObjekte werden dann automatisch (leer) hinzugefügt, z.B. Sportart und Ort. Diese SubObjekte können dann durch den User über bestimmte Formulare bearbeitet und gefüllt werden. Andere Objekte erzeugt der User bei Bedarf komplett neu (z.B. Vereine und deren Mitglieder).
Jedes Objekt beinhaltet seine eigene BL und kann sich bei Bedarf in seinem Umfeld zurecht finden. Starre Verdrahtungen gibt es aber kaum.