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:
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 von Friday:

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:
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 von TiGü:

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. TMySettings .

Deinem tatsächlichen Objekt verpasst du nicht fünf Dutzend Properties, sondern du kannst die 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 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 von Der schöne Günther:

Deinem tatsächlichen Objekt verpasst du nicht fünf Dutzend Properties, sondern du kannst die 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.