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

[Uwe Raabe]

Zitat von mh166:

Zitat von Uwe Raabe:

Hast du schon mal daran gedacht, die Funktionalität von TESPBase in zwei Interfaces zu verlagern? Damit brauchst du nicht mehr die gemeinsame Basisklasse. Das befreit ungemein...

Darüber hatte ich auch nachgedacht. Allerdings sind Interfaces, soweit ich weiß, nur Vorgaben, welche Funktionen implementiert werden müssen. In meinem Fall wäre das ja weniger das Problem: ich kann ja zweimal das gleiche implementieren, wenn ich mag. Nur will ich genau das vermeiden: Ich hätte zweimal 1:1 den gleichen Code, nur für 2 verschiedene Klassen. So zumindest hab ich das mit den Interfaces verstanden.

Solche Doppelimplementationen von Interfaces kann man dann wiederum mit einer Delegation auf eine andere implementierende Klasse auflösen (siehe reserviertes Wort implements).

BTW, könnte es sein, daß du in deinen abgeleiteten Klassen das override unterschlagen hast?

[mh166]

Zitat von Uwe Raabe:

Solche Doppelimplementationen von Interfaces kann man dann wiederum mit einer Delegation auf eine andere implementierende Klasse auflösen (siehe reserviertes Wort implements).

Zugegeben: bei meiner Suche nach Lösungen bin ich ja, wie gesagt, auch schon bei den Interfaces gelandet. Aber irgendwie war für mich die OH-Seite dazu wenig verständlich. Hab dann einfach bei Delphi-Treff das Tutorial zu Interfaces angeschaut. Hättest du eventuell ein kleines Beispiel, wie ich mir das vorstellen kann? =)

Zitat von Uwe Raabe:

BTW, könnte es sein, daß du in deinen abgeleiteten Klassen das override unterschlagen hast?

Öhm ... kööönnte wohl sein. War wohl doch etwas zu pseudo, der Code.

Zitat von Der schöne Günther:

Ein- und Ausgabe von und nach irgendwohin tackere ich mir selbst auch oft an Klassen, die es eigentlich nicht haben sollten. Ich will dich davor bewahren, so zu enden wie ich:
Es ist, wie der Name schon sagt, eine Liste. Kein Webserver-Response-Ausleser. Irgendwann hast du einen Webserver, der dir die Daten anders formatiert. Dann musst du deine Liste von Arbeitnehmern anpassen, nur weil sich ein Webserver geändert hat?

Ich gebe zu ... das ist durchaus plausibel und nachvollziehbar. =)

Zitat von Der schöne Günther:

Grade wenn man einmal damit angefangen hat verleitet es immer weiter, die Klasse mit Dingen aufzublähen die sie nicht haben sollte. Irgendwann kommt eine Methode massenentlassung() welche anhand von irgendwelchen Kriterien Arbeitnehmer auswählt und sie entfernt. Sie stecken zwar in der Liste, aber die Liste selbst hat auch nicht die Filterung zu treffen, wer entfernt wird. Das nur als Beispiel. Schuster, bleib bei deinen Listen (höhö).

Sag das nicht zu laut – so eine Funktion würde unser Betrieb sicher gern mal implementiert sehen.

Zitat von DeddyH:

Günther hat am Samstag aufgepasst

Gabs hier im Forum was aufzupassen? =) Da würde ichs mir gern mal durchlesen, vielleicht ist ja auch für mich was nützliches bei.

[Der schöne Günther]

Zitat von mh166:

Gabs hier im Forum was aufzupassen? =) Da würde ichs mir gern mal durchlesen, vielleicht ist ja auch für mich was nützliches bei.

Das war ein Verweis auf Bernd Uas Vortrag "Besseren Code mit Delphi" vorgestern auf den Delphi-Tagen in Bonn. Ansonsten geht das Buch Clean Code in die selbe Richtung


PS: Die beiden mittleren Zitate waren von mir, werden aber Uwe zugeschrieben. Verrückte Welt. Wenigstens haftet er jetzt juristisch für alle daraus entstehenden Schäden.

[mh166]

Zitat von Der schöne Günther:

Das war ein Verweis auf Bernd Uas Vortrag "Besseren Code mit Delphi" vorgestern auf den Delphi-Tagen in Bonn.

Ist es geplant, davon eine Aufzeichnung online zu stellen? Oder gibt es diese vielleicht ja sogar schon?

Zitat von Der schöne Günther:

PS: Die beiden mittleren Zitate waren von mir, werden aber Uwe zugeschrieben. Verrückte Welt. Wenigstens haftet er jetzt juristisch für alle daraus entstehenden Schäden.

Da hab ich mich wohl verzitiert. Ist jetzt gefixed und du damit ab sofort wieder haftbar.

[Uwe Raabe]

Zitat von mh166:

Zitat von Der schöne Günther:

Das war ein Verweis auf Bernd Uas Vortrag "Besseren Code mit Delphi" vorgestern auf den Delphi-Tagen in Bonn.

Ist es geplant, davon eine Aufzeichnung online zu stellen? Oder gibt es diese vielleicht ja sogar schon?

Dieses Jahr gab es leider keine Aufzeichnungen

[Dejan Vu]

Das Buch 'Clean Code' ist wirklich zum empfehlen. Die deutsche Version ist sehr gut geschrieben und verständlich. Gehört ins Regal wie früher Donald Knuth.

[Uwe Raabe]

Zitat von Dejan Vu:

Gehört ins Regal wie früher Donald Knuth.

Wieso früher?

[mh166]

Zitat von Uwe Raabe:

Dieses Jahr gab es leider keine Aufzeichnungen

Das ist natürlich sehr schade.

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.

[Der schöne Günther]

Kurzfassung:

Delphi-Quellcode:

   // Delegiert das Krachmachen an einen TKrachmacher
   TWurstfabrik = class(TInterfacedObject, IKrachmacher)
      private var
         myKrachmacher: IKrachmacher;
      protected
         property krachDelegate: IKrachmacher
            read myKrachmacher
            implements IKrachmacher;
      public
         constructor Create();
   end;

Langfassung:

Delphi-Quellcode:

program Project2;

{$APPTYPE CONSOLE}

{$R *.res}

uses System.SysUtils;

type
   IKrachmacher = interface
   ['{CB618B3C-8057-4349-8CA3-8047907671A8}']
      procedure macheKrach();
   end;

   TKrachmacher = class(TInterfacedObject, IKrachmacher)
      public procedure macheKrach();
    end;

   // Delegiert das Krachmachen an einen TKrachmacher
   TWurstfabrik = class(TInterfacedObject, IKrachmacher)
      private var
         myKrachmacher: IKrachmacher;
      protected
         property krachDelegate: IKrachmacher
            read myKrachmacher
            implements IKrachmacher;
      public
         constructor Create();
   end;


{ TKrachmacher }

procedure TKrachmacher.macheKrach;
begin
   case Random(3) of
      0: WriteLn('<Ratter, ratter, quietsch>');
      1: WriteLn('*entweichender Dampf*');
      2: WriteLn('*heulende Sirene*');
   end;
end;

{ TWurstfabrik }

constructor TWurstfabrik.Create();
begin
   inherited Create();
   myKrachmacher := TKrachmacher.Create();
end;

var
   myKrachmacher: IKrachmacher;

begin
  try
   myKrachmacher := TWurstFabrik.Create();
   myKrachmacher.macheKrach();
   myKrachmacher.macheKrach();
   myKrachmacher.macheKrach();

  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;

  ReadLn;
end.

Syntaxmäßig ein bisschen lang. implements kann man nur auf (eigentlich überflüssige) Properties anwenden, nicht direkt auf Felder.

[Uwe Raabe]

Zitat von mh166:

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.

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