Daten in Klassen und Records speichern. Zugriffsproblem über mehrere Units

[DieDolly]

Ich kann leider keinen Code schicken, das direkt gesagt. Aber ich erkläre alles so gut ich kann.

Ich habe eine Inidatei mit mehreren Sections drin.
Beim Programmstart lege ich für jede Section eine Klasseninstanz an.
Aktuell sind alle Properties in einer einzigen Unit, in der die Klassendefinition drin steht. Getter und Setter habe ich keine. Read und Write geht direkt auf die Feldvariable.
Das bin ich gerade am ändern und habe diese Unit in mehrere kleine aufgeteilt.

Und jetzt kommt mein Problem.

Pseudocode:
- InstanzVariable := TKlasse.Create;
- InstanzVariable.OptionenA.Modus := <ModusXY>;
- InstanzVariable.OptionenB.Datum := <Timestamp von irgendwann>;
<füge InstanzVariable einer generischen TList hinzu>

OptionenA und OptionenB sind in der Klassendefinition von TKlasse so deklariert

Delphi-Quellcode:

public
  OptionenA: TOptionenA;
  OptionenB: TOptionenB;

TOptionenB steht wieder in einer Extradatei etwa so. TOptionenA ist gleich.

Delphi-Quellcode:

type
 TOptionenB = record
 private
  FDatum: Int64;

  procedure SetDatum(const Value: Int64);
 public
  property Datum: Int64 read FDatum write SetDatum;
 end;

implementation

procedure TOptionenB.SetDatum(const Value: Int64);
begin
 FDatum := Value;

 // XXXXXXXXXXXXXXXXXXXXXX
end;

Und genau da wo XXXXX... steht, habe ich ein Problem. Hier müsste ich auf Modus aus OptionenA der selben Klasseninstanz zugreifen.

Nur wie mache ich das am besten? Ich könnte ganz einfach einen Index in OptionenB hinterlegen und dann damit auf die Liste zugreifen in der alle Instanzen liegen.
Aber das sieht für mich fehleranfällig aus.

[Zacherl]

Sind die Optionen denn so umfangreich, dass es überhaupt Sinn macht hier verschiedene Units anzulegen? Falls das wirklich der Fall sein sollte: Verwende Klassen statt Records, dann kannst du OptionsB einfach im Constructor eine Referenz zu OptionsA mitgeben.

[DieDolly]

Es ist schon ordentlich Code und das wird zu unübersichtlich in einer einzigen Unit.

Ginge das mit der Referenz auch mit Records als Datenhalter?

[Zacherl]

Zitat von DieDolly:

Ginge das mit der Referenz auch mit Records als Datenhalter?

Ginge auch, dann musst du allerdings explizit mit Pointer-Typen arbeiten, also die OptionsB -Instanz als POptionsB = ^TOptionsB übergeben, sonst arbeitest du mit einer lokalen Kopie.

Delphi-Quellcode:

type
  POptionsB = ^TOptionsB;
  TOptionsB = record
    ...
  end;

  TOptionsA = record
  strict private
    FOptionsB: POptionsB;
  public
    ...
    constructor Create(OptionsB: POptionsB);
  end;

[DieDolly]

Das habe ich eben glaube ich schon versucht. Dann ergibt sich ein Problem mit zirkulären Referenzen.

[Zacherl]

Zitat von DieDolly:

Das habe ich eben glaube ich schon versucht. Dann ergibt sich ein Problem mit zirkulären Referenzen.

Die ewige Krux bei Delphi Saubere Klassentrennung wie in C++ mit friend classes ist leider nicht möglich. Dann kannst du höchstens eine "große" Unit basteln, die alle benötigten Klassenbeschreibungen in Form von Interfaces bereitstellt und die Implementierung dann auf einzelne Units splitten.

[DieDolly]

Angenommen ich mache aus OptionenA und OptionenB jetzt eine Klasse.
Wo muss welcher Konstruktor hin und wo muss die Referenz gesetzt werden, damit B > A kennt?


Ok ich glaube das hat sich erledigt. Mit Klassen geht es auch nicht. Eben wegen dem zirkuläre Referenzen Problem.
Ich belasse es dabei, dass alles in eine Unit kommt.

[DieDolly]

Um das abzuschließen.

Ich bin so verblieben, dass ich den gesamten Code in einer Unit habe statt über mehrere verteilt.
Da ich nicht überall Getter- und Setterprozeduren brauche und somit bei Read/Write der Feldvariablen bleiben kann, bleibt die Unit doch relativ klein.

Aktuell 450 Zeilen + Leerzeilen (wovon ich einige mehr habe als normal) sowie Kommentarblöcke. Ein Kommentarblock ohne Inhalt besteht bei mir aus 3 Zeilen (davon habe ich 13).
Im Prinzip also rund 400 Zeilen. Davon sind 220 schon für meine Klassendefinition.

[Zacherl]

Ach, bei 400 Zeilen sehe ich da absolut kein Problem

Habe teilweise solche Monstrositäten, die sich daraus ergeben, dass ich eben die von dir beschriebenen Klassenabhängigkeiten habe und zusätzlich noch interne (Klassen-übergreifende) Felder "private" halten möchte. Letzteres (also das was man z.B. unter C++ als friend class oder Java als package -Sichtbarkeit kennt) geht ja auch nur, wenn die Klassen innerhalb der selben Unit deklariert wurden.

Aber da kann man leider nicht viel machen Die Alternative mit "riesiger" Unit - welche alle Interfaces beinhaltet - sieht man schon häufiger, aber bei den Klassen-übergreifenden private Feldern habe ich dann spätestens bei der Implementierung wieder ein Problem und muss alles in eine Unit klatschen.

[DieDolly]

Gut zu wissen, dass meine paar Hundert Zeilen eine Kleinigkeit sind.

In der Roadmap steht, dass irgendwann auch neue Sprachfeatures kommen sollen.
Wird mal höchste Zeit, dass dieses Problem mit den zirkulären Referenzen behoben und auf den neuesten Stand der Dinge gebracht wird.