Designfrage: Liste selber schreiben? Oder von TList oder TList<T> ableiten?

[Uwe Raabe]

Zitat:

Zitat von mh166 (Beitrag 1271683)

Dürfte ich dich eventuell aber noch einmal um ein Beispiel für diese Delegation der Implementation von Interfaces bitten? :) Ich find irgendwie nix, dass ich so wirklich verstehe. :oops:

Ist zwar auch etwas gekünstelt, aber probieren wir es mal hiermit (Günther's Beispiel ist zugegeben etwas lustiger):

Delphi-Quellcode:

type
  TDumpToJSON = class
  private
    FInstance: TObject;
  protected
    function DumpToJSON: string;
    property Instance: TObject read FInstance;
  public
    constructor Create(AInstance: TObject);
  end;

  IDumpToJSON = interface
    function DumpToJSON: string;
  end;

  TMyClass = class(TInterfacedPersistent, IDumpToJSON)
  private
    FDumpToJSON: TDumpToJSON;
    function GetDumpToJSON: TDumpToJSON;
  protected
    property DumpToJSON: TDumpToJSON read GetDumpToJSON implements IDumpToJSON;
  public
    destructor Destroy; override;
  end;

  TMyOtherClass = class(TInterfacedPersistent, IDumpToJSON)
  private
    FDumpToJSON: TDumpToJSON;
    function GetDumpToJSON: TDumpToJSON;
  protected
    property DumpToJSON: TDumpToJSON read GetDumpToJSON implements IDumpToJSON;
  public
    destructor Destroy; override;
  end;

constructor TDumpToJSON.Create(AInstance: TObject);
begin
  inherited Create;
  FInstance := AInstance;
end;

function TDumpToJSON.DumpToJSON: string;
begin
  result := TJson.ObjectToJsonString(Instance);
end;

destructor TMyClass.Destroy;
begin
  FDumpToJSON.Free;
  inherited Destroy;
end;

function TMyClass.GetDumpToJSON: TDumpToJSON;
begin
  if FDumpToJSON = nil then begin
    FDumpToJSON := TDumpToJSON.Create(Self);
  end;
  result := FDumpToJSON;
end;

destructor TMyOtherClass.Destroy;
begin
  FDumpToJSON.Free;
  inherited Destroy;
end;

function TMyOtherClass.GetDumpToJSON: TDumpToJSON;
begin
  if FDumpToJSON = nil then begin
    FDumpToJSON := TDumpToJSON.Create(Self);
  end;
  result := FDumpToJSON;
end;

Sowohl TMyClass als auch TMyOtherClass leiten die Implementierung des Interfaces an die Instanz einer anderen Klasse TDumpToJSON weiter, die interessanterweise über IDumpToJSON gar nichts weiß.

[Stevie]

Zitat:

Zitat von Uwe Raabe (Beitrag 1271688)

Sowohl TMyClass als auch TMyOtherClass leiten die Implementierung des Interfaces an die Instanz einer anderen Klasse TDumpToJSON weiter, die interessanterweise über IDumpToJSON gar nichts weiß.

Der Nachteil hierbei ist allerdings, dass du hier die Abhängigkeit TDumpToJSON an alle deine IDumpToJSON fähigen Klassen hardcodest.
Und außerdem muss das TDumpToJSON nun für alle Klassen wissen, wie sie zu dumpen sind (wohlmöglich über RTTI, klar das geht).
Aber dann würde ich fragen, warum muss die dann in dem Objekt drin sein und warum muss son Objekt das Interface implementieren?

Bei nem bisschen Stringgematsche für JSON mag das noch harmlos sein, aber dann gehts los und jemand möchte die Instanzen in ner Datenbank speichern und schon haste irgendnen SQL oder Datenbank Zeugs an allen deinen Objekten kleben.

Andere Ansätze sind oft, dass die Klasse, die persistierbar ist, nur die Informationen ausspuckt, die so ein Persistierer benötigt (z.B. RTTI oder was selbstgebautes). Oder dass es ein Interface zum Persistierer übergeben bekommt und dann selbst seine Infos da rein schreibt.

Dann hast du maximal entkoppelte Klassen, so ne Liste oder Objekte wissen gar nix von ihrem Glück, persistierbar zu sein (möglicherweise nur über ihre RTTI/Attribute) und du kannst sie dann an die jeweiligen Instanzen geben, die diesen Job übernehmen.

Misko geht in diesem Artikel ein bisschen auf das Problem von diesen 2 Arten von Objekten ein - solche die einfach nur Daten halten (die er newable nennt) und solchen die wirkliche Arbeit durchführen (Injectables). Und welche Probleme bei der Architektur beim vermischen dieser beiden Arten passieren können.

[mh166]

Vielen Dank an Günther und Uwe: ich glaub ich habs jetzt verstanden. Wobei ich ehrlich gesagt den Umweg über eine extra Property dafür vergleichsweise hacky finde. :? Aber gut, wenn Delphi es so will ... Zumindest weiß ich jetzt, wies funktioniert.

Für den Moment hab ich aber erstmal diese Lösung von Stevie genutzt. Ist an der Stelle die praktikablere Methode für mich, da es nur um drei oder vier Zeilen Code geht, der zweimal dasteht. Ist demnach lesbarer und übersichtlicher wenn man nicht noch 20 Zeilen Interface und Implementierung drumherum baut. :)

Vielen Dank euch allen! Hab wieder ne ganze Menge hierbei gelernt. :thumb: