Interfaces Generics

[Jonas Shinaniganz]

Eine kurze Frage zum Thema.

Wie muss Ich meinen Code ändern damit der "Publisher" Elemente, welche das Interface "ISubscriber" implementieren, aufnimmt?

Delphi-Quellcode:

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

  // Die generische Liste soll Elemente, welche das Interface implementieren, verwalten
  TPublisher = class(TObjectList<ISubscriber>)
  public
    procedure AddSubscriber(ISubscriber);
    procedure RemoveSubscriber(ISubscriber);
    procedure MessageAllSubscriber;
  end;

Ich kann die Generische Klasse aber nur mit einem konkreten Klassen-Parameter vererben oder instanzieren.

Ich will aber das da oben Wieso sollte meiner generischen Liste nicht das Interface genügen? Das wäre echte Kapselung.

Was kann ich machen?

[mjustin]

Zitat von Jonas Shinaniganz:

Eine kurze Frage zum Thema.
Wie muss Ich meinen Code ändern damit der "Publisher" Elemente, welche das Interface "ISubscriber" implementieren, aufnimmt?

Delphi-Quellcode:

type
 ISubscriber = interface
    procedure GetNewspaper(Newspaper : TObject);
  end;

  // Die generische Liste soll Elemente, welche das Interface implementieren, verwalten
  TPublisher = class(TList<ISubscriber>)
  public
    procedure AddSubscriber(S: ISubscriber);
    procedure RemoveSubscriber(S: ISubscriber);
    procedure MessageAllSubscriber;
  end;

Erklärung: TList kann Schnittstellen, TObjectList nicht.

Stilistisch würde ich aber keine AddSubscriber / RemoveSubscriber Methoden deklarieren, denn wenn diese eigenen Code enthalten der in der Oberklasse Add/Remove Methode nicht enthalten ist, könnten Klienten der Klasse weiter auf Add/Remove zugreifen (absichtlich oder unabsichtlich) und damit den eigenen Code umgehen.

[Jonas Shinaniganz]

Liegt das einfach daran, das Add und Sub aus IMath und _AddRef, _Release und QueryInterface aus IInterface dort nicht implementiert sind?

Ich wollte doch auchnoch das Typecasting umgehen. Ach Ich sehe grade, du verwendest auch die generische TList. Okay gut.

Und wenn Ich jetzt noch sowas wie OwnsObjects haben möchte? Selbst schreiben?

[Bummi]

OwnsObjects bei interfaces ?

[Jonas Shinaniganz]

Ja "OwnsObjects bei interfaces" . Das wäre nett.

Aber ich merke schon an der Art deines Posts, da will ich scheinbar zu viel / etwas was nicht möglich ist. Auf das ich mit nachdenken wohl auch selbst kommen sollte.

[Jonas Shinaniganz]

Zitat:

Stilistisch würde ich aber keine AddSubscriber / RemoveSubscriber Methoden deklarieren, denn wenn diese eigenen Code enthalten der in der Oberklasse Add/Remove Methode nicht enthalten ist, könnten Klienten der Klasse weiter auf Add/Remove zugreifen (absichtlich oder unabsichtlich) und damit den eigenen Code umgehen.

Ich wollte eigentlich nur bessere Namen für die Add / Remove Methoden erzielen. Vielleicht sollte Ich die TObjectList besser als Feld meiner TPublisher Klasse deklarieren, ich denke, dann trifft es eher die Art, wie ich sie mir in meinem Konzept ausgedacht habe.

Delphi-Quellcode:

TPublisher 
private
  Subscribers : TList;
public
  procedure AddSubscriber(Subscriber : ISubscriber);
  procedure RemoveSubscriber(Subscriber : ISubscriber);

In dem oberen Beispiel kann Ich ja auch noch die generische Version der TList nehmen.

[Stevie]

Wenn du im zuletzt geposteten Beispiel die Subscriber in einer TList speicherst, haust du dir u.U. den RefCount kaputt. Denn das AddSubscriber sorgt nur für eine weak Reference auf deinen Subscriber (es wird beim adden in die TList, welche ja nur Pointer aufnimmt, kein _AddRef durchgeführt). Wenn dieser Subscriber somit irgendwo out of scope läuft und (sofern du natürlich das automatische Refcounting von TInterfacedObject z.B. benutzt) freigegeben wird, hängt in deiner Subscriber Liste ein dangling Pointer und beim nächsten Zugriff darauf (z.B. durch MessageAllSubscribers) knallts.

[Jonas Shinaniganz]

Okay ich habe scheinbar die IInterfaces noch nicht ganz verstanden.

Hier ist mein Konzept:

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
  protected
    Subscribers : TList<ISubscriber>;
  public
    constructor Create;
    procedure AddSubscriber(Subscriber : ISubscriber); virtual; abstract;
    procedure RemoveSubscriber(Subscriber : ISubscriber); virtual; abstract;
    procedure SendNewsToAllSubs; virtual; abstract;
  end;

Hier sind ein paar konkrete Klassen:

Delphi-Quellcode:

type

  TFAZ = class(TPublisher)
  private
    FCurrentNewspaper : TNewspaper;
    procedure SetCurrentNewspaper(const Value: TNewspaper);
    function GetCurrentNewspaper : TNewspaper;
  public
    procedure AddSubscriber(Subscriber : ISubscriber); override;
    procedure RemoveSubscriber(Subscriber : ISubscriber); override;
    procedure SendNewspaperToAllSubs;
    property CurrentNewspaper : TNewspaper read GetCurrentNewspaper write SetCurrentNewspaper;
  end;

  TFischer = class(TInterfacedObject, ISubscriber)
    procedure GetNewspaper(Newspaper : TNewspaper);
  end;

  TMeier = class(TInterfacedObject, ISubscriber)
    procedure GetNewspaper(Newspaper : TNewspaper);
  end;

Zitat:

Wenn du im zuletzt geposteten Beispiel die Subscriber in einer TList speicherst, haust du dir u.U. den RefCount kaputt. Denn das AddSubscriber sorgt nur für eine weak Reference auf deinen Subscriber (es wird beim adden in die TList, welche ja nur Pointer aufnimmt, kein _AddRef durchgeführt). Wenn dieser Subscriber somit irgendwo out of scope läuft und (sofern du natürlich das automatische Refcounting von TInterfacedObject z.B. benutzt) freigegeben wird, hängt in deiner Subscriber Liste ein dangling Pointer und beim nächsten Zugriff darauf (z.B. durch MessageAllSubscribers) knallts.

Wie verwalte ich denn dann korrekter Weise meine Referenzen? Gibt es die Möglichkeit mir den Referenzzähler der Interface-Klasse zunutzen zu machen? Ist sowas sogar so gedacht? Wie würde ich das denn machen?

Grüße

[mjustin]

Zitat von Stevie:

es wird beim adden in TList, welche nur Pointer aufnimmt, kein _AddRef durchgeführt

Gilt das obige denn auch für die generische TList<Interface>?

[Stevie]

Zitat von mjustin:

Zitat von Stevie:

es wird beim adden in TList, welche nur Pointer aufnimmt, kein _AddRef durchgeführt

Gilt das obige denn auch für die generische TList<Interface>?

Nein, der Compiler sorgt dafür, dass für managed Typen der richtige Source generiert wird (im Falle von Interfaces _AddRef und _Release, bzw IntfCopy).
Daher ist auch eine TList<TFoo> und TList<IFoo> binär inkompatibel, weil für Objekte und Interfaces unterschiedlicher Code generiert wird, obwohl es naiv gesagt beides nur Listen sind, die nen Pointer speichern.

Zitat von Jonas Shinaniganz:

Zitat:

Wenn du im zuletzt geposteten Beispiel die Subscriber in einer TList speicherst, haust du dir u.U. den RefCount kaputt. Denn das AddSubscriber sorgt nur für eine weak Reference auf deinen Subscriber (es wird beim adden in die TList, welche ja nur Pointer aufnimmt, kein _AddRef durchgeführt). Wenn dieser Subscriber somit irgendwo out of scope läuft und (sofern du natürlich das automatische Refcounting von TInterfacedObject z.B. benutzt) freigegeben wird, hängt in deiner Subscriber Liste ein dangling Pointer und beim nächsten Zugriff darauf (z.B. durch MessageAllSubscribers) knallts.

Wie verwalte ich denn dann korrekter Weise meine Referenzen? Gibt es die Möglichkeit mir den Referenzzähler der Interface-Klasse zunutzen zu machen? Ist sowas sogar so gedacht? Wie würde ich das denn machen?

Grüße

Ob du Referenzzählung nutzt oder nicht, hängt wohl von deinem Design ab. Es gibt pro und contra. Das würde aber den Rahmen dieses Thread sprengen, darüber zu philosophieren

Konkret zum Thema hier: Benutz zum Speichern deiner Subscriber TList<ISubscriber>. Ob die Klassen, welche ISubcriber implementieren, Refcounting haben oder nicht, ist dann erstmal irrelevant.