TObjectList<T> und Comparer

[Sir Rufo]

Zitat von OlafSt:

Zitat von Sir Rufo:

Häh? Beim TComparer<T> ? Wo ist denn da was mit einem Hasher? Das kenne ich nur beim TEqualityComparer<T> und das wird z.B. für ein Dictionary benötigt.

Nunja... Ein Druck auf F1, während der Cursor auf einem frisch eingegebenen "TComparer<T>.Construct" steht, führt zum TEqualityComparer. Hab mich auch gefragt, was das wohl mit dem THasher da sein soll, bin aber davon ausgegangen, das der dann wohl optional ist und ein Standard-Hasher genommen wird. Insgesamt ist die OH von XE4 - vorsichtig ausgedrückt - Schrott. Aber einen direkten Weg wie im Visual Studio, wo es direkt ins MSDN geht, ist nicht vorgesehen oder ich habs verkehrt eingestellt. Womit sich die Frage stellt, wo man das einstellt...

Wie dem auch sei, ich hab einiges dazugelernt. So ist

Delphi-Quellcode:

var
   TCo: IComparer<TPosition>;
begin
   FPositions.Sort(TCo);
end;

natürlich Unsinn. Sort weiß ja wirklich nicht, das mein Comparer aufgerufen werden soll, weil TCo=nil. Also gehört da ein TCo:=TPositionComparer.Create; davor. Und genau das ist wohl das verwirrende: Ich muß ein TComparePosition aufrufen, um einen IComparer zu instantiieren.

So langsam raffe ich das Zeug.

Man mag es kaum glauben, aber eine Instanz erzeugt man bei Delphi, wenn man den Konstruktor der Klasse aufruft (es gibt noch andere Wege, aber das ist der klassische Weg).

Und das T davor hat nichts zu sagen, denn es ist einfach nur ein Zeichen, jedes andere Zeichen ist genausogut. Wichtig ist nur, dass ich den exakten Bezeichner der Klasse und nicht die Instanz-Variable benutze.

Delphi-Quellcode:

Foo = class
end;

var
  MyFoo : Foo;
begin
  MyFoo := MyFoo.Create; // kompiliert, ist aber FALSCH
  MyFoo := Foo.Create; 
end;

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

[OlafSt]

Sowas in der Art war auch meine erste Idee, nachdem ich das mit dem Konstruktor, der ein Interface liefert, kapiert hatte.

Ich habe hier eine Anwendung, die von den verschiedensten Telematik-Blackboxes Daten empfangen, verarbeiten und in strukturierter Form verfügbar machen muß. Ein simpler Decoder halt.

Dabei senden manche Boxen per UDP, andere per TCP, ein paar Sonderlinge sogar per SMS Das Protokoll, das da gefahren wird, ist jedesmal unterschiedlich, was aber hinten rauskommen muß, muß stets gleichartig sein. Das können GPS-Daten sein, I/O-Port-Daten, GSM-Infos und vieles mehr. Mal nur eines von denen, mal mehrere, mal ein dutzend von dem, ein paar von jenen.

Schreit nach Interfaces, da das wesentliche immer gleich ist: Connect, CanDecode, Decode, FetchResult.

[Sir Rufo]

Damit das auch noch einen Bezug zum Sort findet:

Delphi-Quellcode:

unit ComparerFun;

interface

uses
  System.SysUtils,
  System.Generics.Defaults;

type
  TInverseComparer<T> = class( TInterfacedObject, IComparer<T> )
  private
    FComparer: IComparer<T>;
    function Compare( const Left, Right: T ): Integer;
    constructor Create( AComparer: IComparer<T> );
  public
    class function Construct( AComparer: IComparer<T> ): IComparer<T>;
  end;

  TConsoleLogStringComparer = class( TInterfacedObject, IComparer<string> )
  private
    FComparer: IComparer<string>;
    function Compare( const Left, Right: string ): Integer;
    constructor Create( AComparer: IComparer<string> );
  public
    class function Construct( AComparer: IComparer<string> ): IComparer<string>;
  end;

implementation

{ TInverseComparer<T> }

function TInverseComparer<T>.Compare( const Left, Right: T ): Integer;
begin
  Result := -FComparer.Compare( Left, Right );
end;

class function TInverseComparer<T>.Construct( AComparer: IComparer<T> ): IComparer<T>;
begin
  Result := Self.Create( AComparer );
end;

constructor TInverseComparer<T>.Create( AComparer: IComparer<T> );
begin
  Assert( Assigned( AComparer ) );
  inherited Create;
  FComparer := AComparer;
end;

{ TConsoleLogStringComparer }

function TConsoleLogStringComparer.Compare( const Left, Right: string ): Integer;
begin
  Result := FComparer.Compare( Left, Right );
  WriteLn( Format( 'Compare( "%s", "%s" ) = %d', [Left, Right, Result] ) );
end;

class function TConsoleLogStringComparer.Construct( AComparer: IComparer<string> ): IComparer<string>;
begin
  Result := Self.Create( AComparer );
end;

constructor TConsoleLogStringComparer.Create( AComparer: IComparer<string> );
begin
  Assert( Assigned( AComparer ) ); // Ein simpler Guard
  inherited Create;
  FComparer := AComparer;
end;

end.

Und ein kleines Progrämmle:

Delphi-Quellcode:

program dp_183670;

{$APPTYPE CONSOLE}
{$R *.res}

uses
  System.SysUtils,
  System.Generics.Defaults,
  System.Generics.Collections,
  ComparerFun in 'ComparerFun.pas';

procedure OutputList( const AList: TList<string> );
var
  LItem: string;
begin
  Write( 'Elemente: ' );
  for LItem in AList do
    begin
      Write( LItem, ' ' );
    end;
  Writeln;
end;

procedure SortElements( const AValues: TArray<string>; AComparer: IComparer<string> );
var
  LList: TList<string>;
begin
  LList := TList<string>.Create;
  try
    LList.AddRange( AValues );
    LList.Sort( AComparer );
    OutputList( LList );
  finally
    LList.Free;
  end;
end;

procedure StartSort;
var
  LComparer: IComparer<string>;
  LValues: TArray<string>;
begin
  LValues := ['foo', 'bar', 'foobar', 'barfoo'];

  Writeln( 'Default-Comparer' );
  LComparer := TComparer<string>.Default;
  SortElements( LValues, LComparer );

  Writeln( 'Invers-Default-Comparer' );
  LComparer := TInverseComparer<string>.Construct( LComparer );
  SortElements( LValues, LComparer );

  Writeln( 'ConsoleLog-Invers-Default-Comparer' );
  LComparer := TConsoleLogStringComparer.Construct( LComparer );
  SortElements( LValues, LComparer );

end;

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

end.

Und man erhält folgende Ausgabe

Code:

Default-Comparer
Elemente: bar barfoo foo foobar

Invers-Default-Comparer
Elemente: foobar foo barfoo bar

ConsoleLog-Invers-Default-Comparer
Compare( "foo", "bar" ) = -4
Compare( "bar", "bar" ) = 0
Compare( "barfoo", "bar" ) = -3
Compare( "foobar", "bar" ) = -4
Compare( "bar", "bar" ) = 0
Compare( "foobar", "bar" ) = -4
Compare( "foo", "barfoo" ) = -4
Compare( "barfoo", "barfoo" ) = 0
Compare( "foobar", "barfoo" ) = -4
Compare( "foo", "foo" ) = 0
Compare( "foobar", "foo" ) = -3
Elemente: foobar foo barfoo bar

[OlafSt]

Eines verstehe ich da nicht: Wozu dient der Parameter AComparer in den class functions/constuctors ?

Wenn ich das recht interpretiere, ist die class function .Construct eine Factory. Die weiß also, was da zu erstellen ist - der Parameter AComparer wird dann dem Konstruktor mitgegeben und einfach nur gespeichert.

Führt das nicht dazu, das der konkrete Comparer eine Referenz auf sich selbst hält ? Ist mir schleierhaft, wofür das gut sein soll...

[Sir Rufo]

Es passiert doch das gleiche wie in dem vorherigen Beispiel. Es wird ein Interface gewrappt