[Interfaces]: Anwendungsbeispiel

[mytar]

Weiss zwar wie Interfaces funktionieren,

finde aber selbst keine guten Anwendungsbeispiele,
d.h. ich möchte ein Interface in eine meiner Anwendungen
implementieren, weiss aber nicht wo. :-D

Danke :-D

[jbg]

Interfaces mit COM oder einfach nur Delphi-Interfaces?

Die Delphi Interfaces eignen sich immer dann, wenn du zwei Units hast, die sich aber beide im interface-Abschnitt brauchen, was ja nicht geht. Dann kann man ein Interface erstellen auf das dann beide Zugreifen, die eine implementierend und die andere nutzend.

[mytar]

*push* :-D

[mirage228]

Zitat:

Zitat von mytar

*push* :-D

WAS willst Du denn mit Interfaces in Deiner Anwendung erreichen?

mfG
mirage228

[PierreB]

das ist genau wie: ich möchte einen button in meinem projekt implentieren, weiß aber net wo ! ;)

das kommt doch darauf an was du damit machen willst ! ^^

[sakura]

Vor allem: beantworte mal die Frage von jbg. Wenn Du das nicht kannst, dann hast Du Interfaces noch nicht einmal ansatzweise verstanden :roll:

...:cat:...

[mytar]

Ich meine Interfaces in bezug auf OOP!

Ich habe öfters in meinen Projekten größere Klassenstrukturen.

Nun möchte ich diese mit teilweise mit Interfaces statt
Klassen ausstatten, welche Vorteile hätte ich damit?
Bitte auch ein paar Anwendungsbeispiele (Klassen wo sich ein Interface eigenen
würde).

Danke

[mytar]

*push* :-D

[Dax]

Wenn du Interfaces statt Klassen nimmst, musst du dich nicht darum kümmern, wann und wie dein Objekt freigegeben wird. Sinnvol ist das zum Beispiel, wenn du ein Objekt nur kurz brauchst, dann nimmt dir das Interface fast die gesamte Arbeit ab. ;)

[mytar]

Ich bräuchte ein Beispiel wo ich statt einer normalen Klasse,
besser ein Interface nehmen sollte (eventuelle Code).

Danke

Dann hätte ich ein gutes Anwendungsbeispiel!
:-D

[Chewie]

Interfaces machen dann Sinn, wenn du Mehrfachvererbung (zwecks polymorphem Verhalten) nachbilden willst, denn eine Klasse kann in OPascal nur von einer erben, aber beliebig viele Interfaces implementieren.

Edit: Ein Interface kannst du dir als eine abstrakte Klasse ohne Felder, bei der alle Methoden abstrakt sind.

[maximov]

Zitat:

Zitat von mytar

Ich bräuchte ein Beispiel wo ich statt einer normalen Klasse,
besser ein Interface nehmen sollte (eventuelle Code).

zB. für das observer-pattern (Beobachter)! Wenn man das nicht mit interfaces macht, so müsste man es starr in die klassen hierarchie einbauen und fremde objekte könnten nicht als beobachter oder beobachtete fungieren, da sie nicht von der klasse abstammen. Nimmt man jetzt ein Interfaces so können alle objekte, die wollen, diese fähigkeiten implementieren. Man lediglich feststellen, ob das interface implmentiert ist.

Da bieten sich 'tausende' sachen an, die auf den ersten blick garnicht danach aussehen :cyclops:

[HeikoDD]

Delphi-Quellcode:

Type
  ixyz = interface
    [guid]
    procedure tutwat; stdcall;
  end;

TXYZ = Class(TInterfacedObject, IXYZ)
  privat
  protected
  public
    procedure tutwat; stdcall;
end;

Var tmp : ixyz;

ixyz = TXYZ.Create();
ixyz.tutwat;

ich hoffe das beantworte die eigentliche frage ein wenig :)

[mytar]

Ja danke :-D

@maximov: Könntest du dieses Observer-Zeug genauer erklären?

@HeikoDD: Ich weiss wie ich dass ganze deklariere, danke!

Bitte weitere Beispiele, danke! :oops:

[mytar]

*push* :firejump:

[maximov]

Zitat:

Zitat von mytar

@maximov: Könntest du dieses Observer-Zeug genauer erklären? ...

Ein observer ist ein software-muster (pattern):

Zitat:

Observer (Beobachter) - Definiere eine 1-zu-n-Abhängigkeit zwischen Objekten, so dass die Änderung des Zustands eines Objekts dazu führt, dass alle abhängigen Objekte benachrichtigt und automatisch aktualisiert werden.

Dazu könnte man ein interface implementieren, welches die nötigen features abstrakt definiert:

Delphi-Quellcode:

type

  INotifyable = interface
    procedure Notification(const NotifyArg:TNotifyArg);
  end;

  IObserveable = interface
    procedure AddObserver(const aObserver:INotifyable);
    procedure RemoveObserver(const aObserver:INotifyable);
  end;

Jedes object, das INotifyable implemntiert kann sich nun bei dem IObserveable-objekt anmelden und wenn es seinen zustand ändert, dann werden alle Notifications, von allen INotifyable-objekten auf gerufen.

Hätte man hier keine interfaces, so müssten sowohl, die procedure von INotifyable, als auch die von IObserveable, tief in der klassen-hierarchie vergraben sein, damit möglichst viele objekte diese fähigkeit besitzen. Das würde aber zu einer starren klassenabhängigkeit führen, mit der man soweiso immer schon kämpfen muss. Interfaces können also dieses problem auflockern und bieten eine prima möglichkeit 'Quer-Einsteiger-funktionalitäten' umzusetzen :wink:

[mytar]

Könntest du mit der Erklärung noch etwas weiter gehen, wass dann folgen würde.

Was ist eine 1 zu n - Beziehung?

Danke, maximov :-D

[mirage228]

Hi,

ich glaube er meint, dass 1 bis n Objekte als Observer an diesem Objekt hängen und dann über das Interface sich eintragen und über das andere Interface benachrichtigt werden.

mfG
mirage228

[phXql]

Zitat:

Zitat von jbg

Interfaces mit COM oder einfach nur Delphi-Interfaces?

Die Delphi Interfaces eignen sich immer dann, wenn du zwei Units hast, die sich aber beide im interface-Abschnitt brauchen, was ja nicht geht. Dann kann man ein Interface erstellen auf das dann beide Zugreifen, die eine implementierend und die andere nutzend.

das is ja interessant. könntest du mir bitte evtl dazu n bisschen sourcecode geben, wenn du hast?

[Jens Schumann]

Zitat:

Zitat von mirage228

Hi,

ich glaube er meint, dass 1 bis n Objekte als Observer an diesem Objekt hängen und dann über das Interface sich eintragen und über das andere Interface benachrichtigt werden.

mfG
mirage228

Nicht ganz. Das heißt, dass 1 Objekt mehrere als Observer bei diesem einen Objekt angemeldete Objekte benachrichtigt. Oder kurz 1 Objekt verwaltet mehrere Objekte

[Jens Schumann]

Hallo,
ich glaube maximov meint soetwas wie dies hier.

Delphi-Quellcode:

unit observer;

interface

uses SysUtils, classes;

Type
  TNotifyArg = class(TObject)
  private
    FMessageText: String;
  public
    property MessageText : String read FMessageText write FMessageText;
  end;

  TObserverNotifycation = procedure(Sender : TObject; MsgText : String) of object;
  INotifyable = interface
   ['{6D8909ED-865B-4F92-A5E5-92195B5FB53D}']
    procedure Notification(const NotifyArg:TNotifyArg);
    function  GetNotify :  TObserverNotifycation;
    procedure SetNotify(const Value : TObserverNotifycation);
    property  OnNotify : TObserverNotifycation read GetNotify write SetNotify;
  end; 

  IObserveable = interface
    ['{D3EB90E2-4D09-4900-A61A-A5AB3D6E4E4B}']
    procedure AddObserver(const aObserver:INotifyable);
    procedure RemoveObserver(const aObserver:INotifyable);
  end;

  TObserver = class(TInterfacedObject,INotifyable)
  private
    FOnNotify: TObserverNotifycation;
    function  GetNotify :  TObserverNotifycation;
    procedure SetNotify(const Value : TObserverNotifycation);
  public
    procedure Notification(const NotifyArg:TNotifyArg);
    property OnNotify : TObserverNotifycation read GetNotify write SetNotify;
  end;

  TMessanger = class(TInterfacedObject, IObserveable)
  private
    FList : IInterfaceList;
  public
    constructor Create;
    destructor  Destroy; override;
    procedure Notify;
    procedure AddObserver(const aObserver:INotifyable);
    procedure RemoveObserver(const aObserver:INotifyable);
  end;

implementation

{ TObserver }

function TObserver.GetNotify: TObserverNotifycation;
begin
  Result:=FOnNotify;
end;

procedure TObserver.SetNotify(const Value: TObserverNotifycation);
begin
  FOnNotify:=Value;
end;

procedure TObserver.Notification(const NotifyArg: TNotifyArg);
begin
  If Assigned(OnNotify) then
    FOnNotify(Self,NotifyArg.MessageText);
end;


{ TMessanger }


constructor TMessanger.Create;
begin
  inherited Create;
  FList:=TInterfaceList.Create;
end;

destructor TMessanger.Destroy;
begin
  inherited Destroy;
end;

procedure TMessanger.AddObserver(const aObserver: INotifyable);
begin
  FList.Add(aObserver);
end;

procedure TMessanger.RemoveObserver(const aObserver: INotifyable);
begin
  FList.Remove(aObserver);
end;

procedure TMessanger.Notify;
var
  iCnt      : Integer;
  NotifyArg : TNotifyArg;
begin
  For iCnt := 0 to FList.Count-1 do
    begin
    NotifyArg:=TNotifyArg.Create;
    Try
      NotifyArg.MessageText:='Notifycation_'+IntToStr(iCnt+1);
      // as ruft hier implizit QueryInterface auf
      (FList[iCnt] as INotifyable).Notification(NotifyArg);
    Finally
      NotifyArg.Free;
      end;
    end;
end;

end.

TObserver implementiert das INotifyable Interface. Dadurch kann eine Instanz von TObserver den Methoden AddObserver und RemoveObserver von TMessanger übergeben werden.

Interessant ist an der Realisierung mit Interfaces, das man auch ein TEdit als Observer bei FMessanger anmelden kann.

Delphi-Quellcode:

TObserverEdit = class(TEdit,INotifyable)

siehe Beispiel.
Wenn ich die Sache richtig verstanden habe können alle Nachfahren von TComponent über Interfaces sehr einfach mit der Observerfähigkeit nachgerüstet werden. Eigene Klassen sollten Nachfahren von TInterfacedObject sein.

Kickt im Beispiel ein paar mal auf den Button "AddObserver" und einmal auf den Button "Create Edit and Add". Anschließend auf den Button "Notify"

[maximov]

Zitat:

Zitat von Jens Schumann

Hallo,
ich glaube maximov meint soetwas wie dies hier.

Genau! ich freu mich, dass du dir die mühe machst und mir die zeilen aus der hand nimmst :-D

Dies wäre eine mögliche technik Observer umzusetzen. In .Net wäre zB. ein Multicast-event geeignet. Oder die VCL hat einen Observer in TComponent, direkt in der klassenstruktur verbuddelt (RegisterNotification). Wobei auch verschiedenste nachrichten verschickt werden können; anstatt der sehr anschaulichen text-botschaft können die objekte auch ereignis-codes, klassen, befehle etc. austauschen, um auf dem neuesten stand zu bleiben.

Wobei Observer hier eigentlich OT sind :cyclops:

mfg,
masimov.


PS: Der vollständigkeit halber, muss man hier noch auf den Ref-counter aufpassen, oder gleich eine InterfaceListe verwenden.

Zitat:

Delphi-Quellcode:

procedure TMessanger.AddObserver(const aObserver: INotifyable); 
begin 
  FList.Add(aObserver); { TODO: _AddRef }
end; 

procedure TMessanger.RemoveObserver(const aObserver: INotifyable); 
begin 
  FList.Remove(aObserver); { TODO: _Release } 
end;

[stoxx]

Hi !

Zitat:

Interessant ist an der Realisierung mit Interfaces, das man auch ein TEdit als Observer bei FMessanger anmelden kann.

Nein, das ist höchst uninteressant !

:duck:

Zitat:

Eigene Klassen sollten Nachfahren von TInterfacedObject sein.

Deswegen (ist es uninteressant)!

.. Maximov, Du hast Recht, es ist eine mögliche Umsetzung, wenn nicht gar die schlechteste.
Das .NET MulticastEvent ist wirklich gut geeignet, allerdings gibts schon seit längerem eine Multicast Umsetzung in Delphi.

http://www.thedelphimagazine.com/disks/dmag53.zip

( Der Ordner Multicas ist der interessante ! )

Mit 3, 4, 5 Befehlen und der Erzeugung von TMulticaster hat man das ganze implementiert.

mfg
stoxx

[Jens Schumann]

[quote="maximov"]PS: Der vollständigkeit halber, muss man hier noch auf den Ref-counter aufpassen, oder gleich eine InterfaceListe verwenden.

Zitat:

Delphi-Quellcode:

procedure TMessanger.AddObserver(const aObserver: INotifyable); 
begin 
  FList.Add(aObserver); { TODO: _AddRef }
end; 

procedure TMessanger.RemoveObserver(const aObserver: INotifyable); 
begin 
  FList.Remove(aObserver); { TODO: _Release } 
end;

Genau, deshalb ist FList auch ein IInterfaceList

[maximov]

Zitat:

Zitat von Jens Schumann

[...]
Genau, deshalb ist FList auch ein IInterfaceList

Schande über mein haupt :duck:

[maximov]

Zitat:

Zitat von stoxx

.. Maximov, Du hast Recht, es ist eine mögliche Umsetzung, wenn nicht gar die schlechteste.
Das .NET MulticastEvent ist wirklich gut geeignet, allerdings gibts schon seit längerem eine Multicast Umsetzung in Delphi.
...

Da sowohl Interfaces, als auch Events zur entkopplung dienen, sind sie beide geeignet und haben in diesem anwendungs gebiet ihre vor-und nachteile - ABER hier geht es um interfaces und mögliche anwendungsbeispiele, also ist eine diskusion über multicasts, und was der beste observer ist, irrelevant!

[OT]Wobei mich die möglichkeit von win32 multicasts nicht überrascht, da mit klassen eh irgendwie alles möglich ist und ich selbst auch schon Multicaster geschrieben habe.[/OT]

:stupid: