Datenstruktur: Kindobjekt als Objekt oder Record

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

[Der schöne Günther]

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

[Uwe Raabe]

Zitat von Der schöne Günther:

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.

[Friday]

Zitat von Der schöne Günther:

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

Der auf dem Schlauch steht bin wohl ich selbst
Hatte das mehrfach gelesen, aber immer falsch verstanden. Records können natürlich keine Interfaces implementieren im Sinne von
MyRec = Record(IMyInterface) Aber sehr wohl interfaces als Felder oder properties haben.

OK...also nochmal weniger das gegen Records spricht.

Aber wie seht ihr das Argument den Stack nicht unnötig mit langlebigen Daten zu befüllen? (Die noch dazu keinen Geschwindigkeitsvorteil benötigen weil selten kopiert)