TObjectList<T> und Comparer

[Der schöne Günther]

Richtig- In Sachen Vererbung ist das ja im Endeffekt auch nichts anderes: Du rufst evtl. ein THund.Create() auf und weist das einer TTier -Variable zu. Alles klar soweit in Sachen Interfaces? Das Sortieren mit IComparer<T> und allem ist da schon viel knackiger, finde ich.

Die Doku ist inhaltlich oft falsch, der Kram hinter der F1-Taste nicht zu gebrauchen. Der tatsächliche Inhalt zu System.Generics.Defaults.TComparer.Compare ist aber hier ausnahmsweise sehr brauchbar, finde ich.

Hier mal ein Beispiel mit Integern:

Delphi-Quellcode:

program Project19;

{$APPTYPE CONSOLE}

{$R *.res}

uses System.SysUtils, System.Generics.Collections, System.Generics.Defaults;

type
   /// <summary>
   ///     Vergleicht <c>Integer</c>, jedoch in <b>absteigender</b> Reihenfolge:
   ///    Für diesen Comparer ist <c>5 &gt; 42</c>
   /// </summary>
   TMyReversedIntegerComparer = class(TComparer<Integer>)
      function Compare(const Left, Right: Integer): Integer; override;
   end;

procedure justSortingThings();
var
   myList:            TList<Integer>;
   descendingComparer: IComparer<Integer>;
   item:            Integer;
begin
   myList := TList<Integer>.Create();
   myList.AddRange([5, 42, 5, 99, -37]);

   WriteLn('Normales Sortierverhalten: ');
   myList.Sort();
   for item in myList do WriteLn(item);

   WriteLn(sLineBreak);

   WriteLn('Mein eigenes Sortierverhalten: ');
   descendingComparer := TMyReversedIntegerComparer.Create();
   myList.Sort(descendingComparer);
   for item in myList do WriteLn(item);

   myList.Destroy();
end;


{ TMyReversedIntegerComparer }

function TMyReversedIntegerComparer.Compare(const Left, Right: Integer): Integer;
begin
   Result := -(Left - Right);
end;

begin
  try
   ReportMemoryLeaksOnShutdown := True;
   justSortingThings();
  except
   on E: Exception do
     Writeln(E.ClassName, ': ', E.Message);
  end;
  readln;
end.

Ich persönlich würde es auch mit einer anonymen Methode machen aber im Endeffekt ist es das gleiche.

[OlafSt]

Jetzt kapiere ich auch solchen Code, lieber Günther

Natürlich ist es einfacher und kompakter, eine anonyme Methode zu verwenden. Doch wenn jemand wie ich irgendwann einen Zug verpaßt hat und Interfaces seitdem als großes Mysterium ansieht, dann kapiert man nie die Zusammenhänge.
Darum habe ich den ausführlichen Weg gewählt. Nun weiß ich, das ein Iirgendwas nur eine Schablone darstellt, keine Klasse. Mir ist klargeworden, das ich ein Tirgendwas brauche, damit ich Programmcode hinter das Iirgendwas kriege. Das ich einen Tirgendwas-Konstruktor aufrufen muß, um ein Iirgendwas zu erzeugen. Und das ich am Ende auf ein .Free verzichten kann.

All diese Hintergründe sieht man nicht - und kapiert sie folglich auch nicht - wenn man die Abkürzung nimmt. Wenn dann die OH auch noch in die falsche Richtung schubst bzw. völlig nichtssagend ist, stehst auf verlorenem Posten und es entstehen Kopfschüttler-Threads wie dieser hier

Sokath, seine Augen geöffnet !

[stahli]

Ich finde den Anwendungsfall nicht geeignet um die Sinnhaftigkeit von Interfaces zu diskutieren.

Der Comparer kann als normale Objektinstanz erzeugt werden und wird dann einfach als Interface weiter verabeitet.
Ich bin da etwas drüber gestolpert (http://www.delphipraxis.net/180504-g...nd-contra.html -> #14), weil ich das vermeintliche Objekt wieder freigegeben hatte - was dann zu Problemen führte.
Aber ansonsten ist es ja nicht weiter relevant, dass da ein Interface im Spiel ist.

Wenn Du Dich für Interfaces interessierst solltest Du mal hier suchen. Da gab es viele Diskussionen dazu.
Ich nutze das jetzt auch schon umfangreich.

Die Vorteile sind vor allem:
- Objekte müssen nicht aufgelöst werden
- Klassen müssen nicht veröffentlicht werden
- Objekte können mehere Schnittstellen unterstützen

Das sollte aber besser direkt in Interface-Threads besprochen werden.

[Sir Rufo]

@stahli *hüstel*

Es gibt da so eine Besonderheit mit den Interfaces und der direkten Argumentsübergabe. Das ist auch ein Grund, warum es bei den ganzen Comparer-Erzeugern eine class function Construct gibt und der normale constructor Create versteckt ist.

Nehmen wir mal das Eingangs-Beispiel

Delphi-Quellcode:

var
   TCo: TPositionComparer;
  LPC : IComparer<TPosition>
begin
  FPositions.Add(Result);
  TCo := TPositionComparer.Create;

  // ACHTUNG! TCo ist keine Interface-Variable, 
  // wird aber jetzt als Interface übergeben (Sort Argument)
  // und nach dem Sort ist die Instanz durch die Referenz-Zählung
  // zerstört. In TCo finden wir nur noch einen nutzlosen Referenz-Zeiger

  FPositions.Sort( TCo );
  FPositions.Sort( TCo ); // hier rummst es jetzt

  // besser so:

  LPC := TPositionComparer.Create;
  FPositions.Sort( LPC );
  FPositions.Sort( LPC ); // alles ok, denn LPC ist eine Interface-Variable

  // jetzt das Beste zum Schluss

  FPositions.Sort( TPositionComparer.Create );
  FPositions.Sort( TPositionComparer.Create ); // alles ok, alles funktioniert

  // wirklich alles? NEIN, wir haben ein Speicherleck produziert
end;

Bei der direkten Argumentsübergabe der Referenz, wird der Referenz-Zähler nicht erhöht, darum auch nicht verringert, dadurch wird kein _AddRef und kein _Release aufgerufen, und dadurch wird die Instanz nicht freigegeben.

[stahli]

Ja, ok, das ist schon i.O.

Ich hatte den Eingangspost so verstanden, dass er sich (Anmerkung der Redaktion: "jetzt endlich mal richtig") mit "Interfaces auseinandersetzen" will.

Das Beispiel zeigt aber erst mal nur, wie man den Comparer benutzt.
Hier würde ich noch nicht ableiten, wozu Interfaces gut sind.

Ich wollte nur hinweisen, dass es gute Gründe für Interfaces gibt, die auch schon umfangreich diskutiert wurden (ich hatte vor einiger Zeit auch schon einiges dazu zusammen gesucht) und dass sich diese aus dem Bespiel noch nicht erkennen lassen.

[OlafSt]

Ich habe mich schon oft an Interfaces versucht, Gerade in C# ist man mit denen ständig beschäftigt. Aber ich verstand nie die Mechaniken, wie man es nun konkret anwendet. Schon gar nicht in Delphi.
Ich habe die Angewohnheit, erstmal zu begreifen, wie "das alles funktioniert". Ideen, wo man das dann einsetzen kann, kommen dann quasi von selbst. Da mir das ganze in Delphi immer ein Rätsel war, habe ich TObjectList<T>.Sort einfach als Aufhänger benutzt um ein für alle mal in den Kopf zu kriegen, wie das läuft.

Aus meiner Sicht hatte .Sort quasi das Pech, dafür herhalten zu müssen. Ich mußte erst selbst erkennen, das man eine Klasse braucht, um ein Interface zu implementieren (ein Fakt, der nie in dieser Form erwähnt wurde oder den ich nie realisiert habe ). Das man dann den Konstruktor so einer Klasse aufruft, ist eigentlich logisch - warum dieser Aufruf aber nun plötzlich einen IComparer ergibt, statt eines TPositionComparer, war mir auch immer ein Rätsel. An das nicht-mehr-freigeben-müssen muß man sich auch erstmal gewöhnen (ich erwische mich ständig dabei, in C# immer wieder Routinen so zu bauen, das ich am Ende alles aufräumen kann ).

Ganz ehrlich: Ich benutze ganz bestimmt nicht etwas, von dem ich nicht mal weiß, wie ich es instanziert bekomme.

Dieses Problem ist vom Tisch. Der Rest findet dann in den geeigneteren Unterforen statt

[Sir Rufo]

Hier mal ein kleines Beispiel mit Interfaces

Wir habe da einen Dienst, der uns einen ganz simplen Text liefert.

Delphi-Quellcode:

unit DatenHoler;

interface

type
  IDatenHoler = interface
    ['{4C5405CE-04AF-43C0-BB06-00C1051C12D8}']
    function HoleDaten: string;
  end;

implementation

end.

Konkret bekommen wir diese Daten per HTTP geliefert und es dauert pro Abfrage eine Sekunde bis wir die Daten bekommen.

Delphi-Quellcode:

unit HttpDatenHoler;

interface

uses
  DatenHoler;

type
  THttpDatenHoler = class( TInterfacedObject, IDatenHoler )
  public
    function HoleDaten: string;
  end;

implementation

uses
  System.SysUtils;

{ THttpDatenHoler }

function THttpDatenHoler.HoleDaten: string;
begin
  Sleep( 1000 );
  Result := 'Hier sind die Daten ' + DateTimeToStr( Now );
end;

end.

Das ganze sieht dann so aus:

Delphi-Quellcode:

procedure BenutzeDatenHoler( ADatenHoler: IDatenHoler );
var
  LIdx: Integer;
begin
  for LIdx := 1 to 10 do
    begin
      Write( DateTimeToStr( Now ), ': ' );
      Writeln( ADatenHoler.HoleDaten );
    end;
end;

procedure Start;
var
  LDatenHoler: IDatenHoler;
begin
  Writeln( 'Direkte Anfrage an den DatenHoler' );
  LDatenHoler := THttpDatenHoler.Create;
  BenutzeDatenHoler( LDatenHoler );
end;

Ist ja ganz witzig, aber irgendwie dauert mir jede Abfrage zu lange, aber in meiner Anwendung merken will ich mir das trotzdem nicht ... egal, wir haben ja gegen ein Interface programmiert und machen einfach mal das hier:

Delphi-Quellcode:

unit CachedDatenHoler;

interface

uses
  DatenHoler;

type
  TCachedDatenHoler = class( TInterfacedObject, IDatenHoler )
  private
    FDatenHoler: IDatenHoler;
    FHasCachedData: Boolean;
    FCachedData: string;
  public
    constructor Create( ADatenHoler: IDatenHoler );
    function HoleDaten: string;
  end;

implementation

{ TCachedDatenHoler }

constructor TCachedDatenHoler.Create( ADatenHoler: IDatenHoler );
begin
  inherited Create;
  FDatenHoler := ADatenHoler;
end;

function TCachedDatenHoler.HoleDaten: string;
begin
  if not FHasCachedData
  then
    begin
      FCachedData := FDatenHoler.HoleDaten;
      FHasCachedData := True;
    end;
  Result := FCachedData;
end;

end.

Und ändern (nur) den Start wie folgt ab:

Delphi-Quellcode:

procedure Start;
var
  LDatenHoler: IDatenHoler;
begin
  Writeln( 'Cache Anfrage an den DatenHoler' );
  LDatenHoler := THttpDatenHoler.Create;
  LDatenHoler := TCachedDatenHolder.Create( LDatenHoler );
  BenutzeDatenHoler( LDatenHoler );
end;

Schon gehts nach der ersten Abfrage ab wie der Wind und meine Anwendung musste ich auch nicht ändern

Man beachte, dass der TCachedDatenHoler keinerlei Kenntnis von dem THttpDatenHoler hat, der eigentlich die Daten besorgt. Da macht ein Interface dann richtig Spass.