Interfaces Generics

[Jonas Shinaniganz]

Folgendes kommt aus der Delphi Referenz:

Zitat:

Anmerkung: __AddRef und _Release können auch so implementiert werden, dass sie keine Referenzzählung durchführen. Bei solchen Objekten erreicht der Referenzzähler niemals den Wert Null, sodass das Objekt nicht automatisch freigegeben wird. In diesen Fällen muss die Anwendung für die Freigabe des Objekts sorgen.

Also wenn ich immer meine Objekte von TFischer / TMeier aus der Liste mit RemoveSubscriber entferne und auch selbst den Speicher von allen erzeugten Objekten wieder Freigebe dann sollte ich doch keine Probleme bekommen oder?

Allerdings schaffe ich es nicht, dass meine Objekte sich automatisch (zb im destructor) aus der Liste austragen, so wie mein Konzept bisher ist.

[Sir Rufo]

Warum sollten sich deine Objekte auch selber aus der Liste austragen?

Ein Interface hat den besonderen Vorteil, dass es sich selber aus dem Speicher entfernt, wenn keiner mehr etwas von ihm wissen möchte.

Nehmen wir an dein System verwaltet die Newspaper von 3 Publishern.
Bei allen tragen sich ein paar Leutchen als Empfänger (Subscriber) ein, davon einige auch bei 2 oder sogar 3 Publishern.

Irgendwann hat einer (Subscriber) keine Lust mehr und meldet sich von einem Publisher wieder ab.

Ist dieser jenige Subscriber bei keinem anderen Verlag mehr angemeldet, dann verschwindet er automatisch aus dem System. Das ist auch gut so, denn für die Verwaltung wird diese Person nicht mehr benötigt. Er bekommt ja von keinem mehr ein Newspaper, wozu also damit noch belasten.

Es funktioniert also genau anders herum. Das Objekt (Interface) wird nicht gelöscht und dadurch aus den Listen entfernt, sondern wenn es aus allen Listen entfernt wurde, dann verschwindet es im Daten-Nirwana.

Deine Deklaration vom Publisher ist etwas suboptimal. Wozu sind die Methoden als virtual; abstract; deklariert?
Diese Methoden sind für alle abgeleiteten Klassen gleich und können direkt in TPublisher implementiert werden.
Und wie willst du in einer abgeleiteten Klasse auf das private (upps, das war ja protected ... o graus) Feld FSubscribers zugreifen? Das würde nur funktionieren, wenn sich die abgeleiteten Klassen in der selben Unit befinden.

Delphi-Quellcode:

type
  TNewspaper = class
  private
    FTitle : String;
    procedure SetTitle(const Value : String);
  public
    property Title : String read FTitle write SetTitle;
  end;

  ISubscriber = interface
    procedure GetNewspaper(Newspaper : TNewspaper);
  end;

  TPublisher = class
  private
    FSubscribers : TList<ISubscriber>;
  public
    constructor Create;
    destructor Destroy; override;
    procedure AddSubscriber(Subscriber : ISubscriber);
    procedure RemoveSubscriber(Subscriber : ISubscriber);
    procedure SendNewsToAllSubs( Newspaper : TNewspaper );
  end;

implementation

constructor TPublisher.Create;
begin
  inherited;
  FSubscribers := TList<ISubscriber>.Create;
end;

destructor TPublisher.Destroy;
begin
  FSubscribers.Free;
  inherited;
end;

procedure TPublisher.AddSubscriber(Subscriber : ISubscriber);
begin
  FSubscriber.Add( Subscriber );
end;

procedure TPublisher.RemoveSubscriber(Subscriber : ISubscriber);
begin
  FSubscriber.Remove( Subscriber );
end;

procedure TPublisher,SendNewsToAllSubs( Newspaper : TNewspaper );
var
  LSubscriber : ISubscriber;
begin
  for LSubscriber in FSubscribers do
    LSubscriber.GetNewspaper( Newspaper );
end;

Ab jetzt kann jeder Publisher Subscriber aufnehmen und entfernen, sowie Newspaper an seine Subscriber ausliefern, ohne bei der Ableitung noch weiteren Code hinzufügen zu müssen.

[Elvis]

Mag offtopic sein, aber BÜDDE, BÜDDE, mit Zucker obendrauf: Benutzt richtige Calling canventions wenn ihr schon Interfaces nehmt.

Delphi Interfaces sind COM-kompatibel. Man könnte also eigentlich problemlos Implemtierungen in C#, C++, FPC, D, etc. erzeugen.
Aber nur wenn nicht Borlands Fastcall AKA register benutzt wird!
Also safecall oder stdcall, aber nicht gar nix...

Wollte letztlich was mit der OTA machen und hatte ein recht schmerzhaftes Facepalm als ich sah, dass die Honks von Borland die OTA-Interfaces tatsächlich in register geschrieben haben.

[JamesTKirk]

Zitat von Elvis:

Mag offtopic sein, aber BÜDDE, BÜDDE, mit Zucker obendrauf: Benutzt richtige Calling canventions wenn ihr schon Interfaces nehmt.

Delphi Interfaces sind COM-kompatibel. Man könnte also eigentlich problemlos Implemtierungen in C#, C++, FPC, D, etc. erzeugen.
Aber nur wenn nicht Borlands Fastcall AKA register benutzt wird!
Also safecall oder stdcall, aber nicht gar nix...

Ich weiß jetzt nicht, wofür Jonas Shinaniganz die Interfaces benötigt, aber ich selbst würde spezifische Calling Conventions nur dann verwenden, wenn ich die Interfaces auch wirklich exportiere. Ansonsten nehme ich den Default und der ist nun mal unter x86 register .

Gruß,
Sven

[Elvis]

Zitat von JamesTKirk:

Ich weiß jetzt nicht, wofür Jonas Shinaniganz die Interfaces benötigt, aber ich selbst würde spezifische Calling Conventions nur dann verwenden, wenn ich die Interfaces auch wirklich exportiere. Ansonsten nehme ich den Default und der ist nun mal unter x86 register .

Und in der nächsten Version willst du dann auch Plugins erlauben, und die kann man dann nur mit Delphi/BCB oder vllt FPC schreiben.

Oder du willst eine Funktion aus .Net/C++/.etc benutzen, und kannst deine Instanzen nicht direkt übergeben, sondern musst sie erst verpacken, nur weil du kein "safecall" oder "stdcall" hinter die Methoden namen packen wolltest.

Klasse!

[Stevie]

Zitat von Elvis:

Mag offtopic sein, aber BÜDDE, BÜDDE, mit Zucker obendrauf: Benutzt richtige Calling canventions wenn ihr schon Interfaces nehmt.

Delphi Interfaces sind COM-kompatibel. Man könnte also eigentlich problemlos Implemtierungen in C#, C++, FPC, D, etc. erzeugen.
Aber nur wenn nicht Borlands Fastcall AKA register benutzt wird!
Also safecall oder stdcall, aber nicht gar nix...

Wollte letztlich was mit der OTA machen und hatte ein recht schmerzhaftes Facepalm als ich sah, dass die Honks von Borland die OTA-Interfaces tatsächlich in register geschrieben haben.

Nur, weil die Delphi Interfaces COM kompatibel sind, heißt das nicht, dass man überall eine COM kompatible Calling convention benutzen muss.
Falls man wirklich mal Compiler übergreifend arbeiten will, ist wohl stdcall hinten dran schreiben das geringste Problem oder benutzt du in Interfaces Signaturen nur COM kompatible Datentypen (TObject in C#? Viel Spaß!)