Datenstruktur: Kindobjekt als Objekt oder Record

[Friday]

Hallo,

ich habe ein InterfacedObject mit vielen Eigenschaften, wobei die Eigenschaften vermutlich noch weiter anwachsen werden.
Um das einigermaßen übersichtlich und wartbar zu halten, wollte ich entsprechend Kindobjekte mit Eigenschaften erstellen. Hierbei stellt sich die Frage ob Objekt oder Record.

Objekt:

Delphi-Quellcode:

TMyObj = class(TInterfacedObject, MyInterface)
 Field_A0
 Field_A1
 ...
 Field_A9
 Field_B0
 ...
 Field_B9
 ...
 Field_F9

Hier sind beispielhaft nur die Feldnamen gelistet, properties, getter und setter bitte dazu denken. In dem Beispiel sind das also 60 Eigenschaften.
Eine Möglichkeit wäre für alle A, B, C, D, E, F - Eigenschaften je ein Objekt oder Record als Kindobjekt zu definieren.
Als Interfaces:

Delphi-Quellcode:

TMyObj = class(TInterfacedObject, MyInterface)
 Field_A: IGrpA;
 Field_B: IGrpB;
 Field_C: IGrpC;
 Field_D: IGrpD;
 Field_E: IGrpE;
 Field_F: IGrpF;

Um der Dependency Injection gerecht zu werden, würde der constructor also so aussehen:

Delphi-Quellcode:

constructor TMyObj.create(aGrpA: IGrpA; aGrpB: IGrpB; aGrpC: IGrpC; aGrpD: IGrpD; aGrpE: IGrpE; aGrpF: IGrpF);

Unnötig zu sagen, das grenzt wieder an Unübersichtlichkeit und überschreitet eine vernünftige Anzahl an Parametern.
Statt dessen alle Kindobjekte als Records erstellen scheint fast naheliegender. Der Nachteil ist, dass es eher langlebige Daten sind und so doch einige Daten (es kommen auch einige Instanzen von TMyObj zusammen) auf dem Stack landen ohne dessen Geschwindigkeit zu benötigen. Die Kindobjekte selbst werden keine Interfaces als Eigenschaften haben, womit Records grundsätzlich möglich sind. Auch Vererbung ist hier kein Thema.
Ach ja: Das Thema ByValue oder ByRef spiel hier auch eher eine untergeordnete Rolle, da es nicht zu großen Kopiervorgängen kommt. Zumindest nicht von den Kindobjekten, sondern wenn dann von TMyObj.

Zu welcher Lösung würdet ihr greifen? Oder nochmal zu einer anderen?

Danke schonmal.

[TiGü]

Zitat:

Zitat von Friday (Beitrag 1505417)

Als Interfaces:

Delphi-Quellcode:

TMyObj = class(TInterfacedObject, MyInterface)
 Field_A: IGrpA;
 Field_B: IGrpB;
 Field_C: IGrpC;
 Field_D: IGrpD;
 Field_E: IGrpE;
 Field_F: IGrpF;

Um der Dependency Injection gerecht zu werden, würde der constructor also so aussehen:

Delphi-Quellcode:

constructor TMyObj.create(aGrpA: IGrpA; aGrpB: IGrpB; aGrpC: IGrpC; aGrpD: IGrpD; aGrpE: IGrpE; aGrpF: IGrpF);

Unnötig zu sagen, das grenzt wieder an Unübersichtlichkeit und überschreitet eine vernünftige Anzahl an Parametern.

Delphi-Quellcode:

type
  TMyObjData = record
      GrpA: IGrpA;
      GrpB: IGrpB;
      GrpC: IGrpC;
      GrpD: IGrpD;
      GrpE: IGrpE;
      GrpF: IGrpF;
  end;

//...

constructor TMyObj.Create(const AMyObjData: TMyObjData);
begin
  Self.FMyData := AMyObjData;
  // Tataa, fertig! Super erweiterbar, man muss die Methodensignatur des Constructors nicht mehr anpacken!
end;

Jetzt kannst du dir noch aussuchen, ob du deine öffentlichen Properties auf das gesamte Sammel-Record zeigen lässt oder auf die einzelnen Bestandteile davon.

[Friday]

Zitat:

Zitat von TiGü (Beitrag 1505418)

Delphi-Quellcode:

type
  TMyObjData = record
      GrpA: IGrpA;
      GrpB: IGrpB;
      GrpC: IGrpC;
      GrpD: IGrpD;
      GrpE: IGrpE;
      GrpF: IGrpF;
  end;

TMyObj enthält mind. 2 einzelne Interface Eigenschaften, von daher darf es kein Record sein. Die Frage stellt sich also wirklich nur für die Kindobjekte.

[TigerLilly]

Hmm. Ich kenn deine Anforderung nicht, aber ich würde eine dynamische Struktur bauen:

TMyObj = class(TInterfacedObject, MyInterface)
fEigenschaften: TList<TEigenschaft,TWert>;
end;

Ob TList oder sonstwas ist da jetzt eagl.

[Der schöne Günther]

Es sind doch nur Daten, sie tun nichts. "Plain Old Data", in Delphi praktisch immer ein Record, z.B.

Delphi-Quellcode:

TMySettings

.

Deinem tatsächlichen Objekt verpasst du nicht fünf Dutzend Properties, sondern du kannst die

Delphi-Quellcode:

TMySettings

lesen, und du kannst sie setzen. Später willst du diese Einstellungen dauerhaft speichern und laden oder übers Netz übertragen, und kümmerst dich um die Serialisierung von

Delphi-Quellcode:

TMySettings

. Wer oder was das benutzt ist unerheblich.

Wenn du wirklich meinst dass sich messbare Performance-Einbußen über das Pass by value ergeben lässt sich das ganze ja notfalls auch noch über einen Referenztyp wrappen, aber die Daten selbst - Da sehe ich nie was man dadurch gewinnt, das in ein TObject oder gar interface-basiertes Objekt zu verpacken, außer noch mehr Tipparbeit und Komplexität.

[Friday]

Zitat:

Zitat von Der schöne Günther (Beitrag 1505422)

Deinem tatsächlichen Objekt verpasst du nicht fünf Dutzend Properties, sondern du kannst die

Delphi-Quellcode:

TMySettings

lesen, und du kannst sie setzen.

Du sprichst dich also für die Lösung von TiGü aus. Aber wie gesagt, das funktioniert nicht weil TMyObj mind. 2 Interfaces als properties hat.

[Der schöne Günther]

Ich stehe auf dem Schlauch - Inwiefern ist das ein Problem?

[Uwe Raabe]

Zitat:

Zitat von Der schöne Günther (Beitrag 1505424)

Ich stehe auf dem Schlauch

Kann ich mich anschließen. Allerdings habe ich überhaupt noch nicht verstanden, was denn eigentlich erreicht werden soll. Im Moment sehe ich nur vage Fetzen vom Ganzen und ich will mir den Rest nicht einfach dazu denken.

[TiGü]

Bin auch Schlauchsteher!
Welches technische Problem steht dem im Weg?

[stahli]

Grundsätzlich stellt sich ja die Frage:

- Warum soll ich ein Object, InterfacedObject oder Record verwenden?

Alles hat Vor- und Nachteile.

Ein Record ist schlank aber bei Übergaben werden die Values normalerweise kopiert, was langsam sein kann (wenn man nicht Pointer benutzt).
Ein InterfacedObject ist langsam und speicherhungrig. Dafür kann man sie leicht referenzieren, sie "teilen Funktionalitäten" und sie können automatisch freigegeben werden.
Ein Object ist nicht ganz so langsam und speicherhungrig, kann leicht referenziert werden, unterstützt Vererbung, muss aber freigegeben werden.

Für Eigenschaften Deiner Klasse stellt sich die gleiche Frage.
Interface-Funktionalitäten brauchst Du dafür offenbar nicht - also kannst Du Dir den Aufwand sparen.
Bleiben Records und Klassen.
Wenn Du diese ständig weitergeben musst, würden sich wohl Klassen anbieten, ansonsten Records.