Tutorial Interfaces

[DeddyH]

Exakt, ich habe da mal schnell ein Beispiel gebaut (ich habe die Standard-Benennung einfach beibehalten, da die Komponenten eh keinen tieferen Sinn haben):

Delphi-Quellcode:

unit Unit6;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls;

type
  IDisplay = interface
    ['{B515DBE1-9D0E-4491-BEE8-85805852870B}']
    function DisplayString: string;
  end;

  TEdit = class(VCL.StdCtrls.TEdit, IDisplay)
  public
    function DisplayString: string;
  end;

  TLabel = class(VCL.StdCtrls.TLabel, IDisplay)
  public
    function DisplayString: string;
  end;

  TComboBox = class(VCL.StdCtrls.TComboBox, IDisplay)
  public
    function DisplayString: string;
  end;

  TWuppdi = class
    procedure Consume(const Display: IDisplay);
  end;

  TForm6 = class(TForm)
    Edit1: TEdit;
    ComboBox1: TComboBox;
    Label1: TLabel;
    Button1: TButton;
    Button2: TButton;
    Button3: TButton;
    procedure Button1Click(Sender: TObject);
    procedure FormCreate(Sender: TObject);
    procedure FormDestroy(Sender: TObject);
    procedure Button2Click(Sender: TObject);
    procedure Button3Click(Sender: TObject);
  private
    { Private-Deklarationen }
    FWuppdi: TWuppdi;
  public
    { Public-Deklarationen }
  end;

var
  Form6: TForm6;

implementation

{$R *.dfm}

{ TEdit }

function TEdit.DisplayString: string;
begin
  Result := Text;
end;

{ TLabel }

function TLabel.DisplayString: string;
begin
  Result := Caption;
end;

{ TComboBox }

function TComboBox.DisplayString: string;
begin
  if ItemIndex > -1 then
    Result := Items[ItemIndex]
  else
    Result := '';
end;

{ TWuppdi }

procedure TWuppdi.Consume(const Display: IDisplay);
begin
  ShowMessage(Display.DisplayString);
end;

procedure TForm6.Button1Click(Sender: TObject);
begin
  FWuppdi.Consume(Edit1);
end;

procedure TForm6.Button2Click(Sender: TObject);
begin
  FWuppdi.Consume(ComboBox1);
end;

procedure TForm6.Button3Click(Sender: TObject);
begin
  FWuppdi.Consume(Label1);
end;

procedure TForm6.FormCreate(Sender: TObject);
begin
  FWuppdi := TWuppdi.Create;
end;

procedure TForm6.FormDestroy(Sender: TObject);
begin
  FWuppdi.Free;
end;

end.

[Bbommel]

Hm, du meinst, dass du sowas machen könntest?

Delphi-Quellcode:

  TRumsButton = class(TButton,ISuperIntf)
  public
    procedure Blubb;
  end;

[...]
var
  customer: TCustomer;
  rums: TRumsButton;
begin
[...]
  customer.wuppdi(rums);
[...]
end;

Wäre das von der Synatx her richtig und das, was du meinst? Okay, zugegeben, das ginge mit abtrakten Klassen nicht.

PS: Edith hat sich gemeldet, aber ich poste es dennoch mal, um bei den vorherigen, ganz einfachen Beispielen zu bleiben.

[Uwe Raabe]

Zitat:

Zitat von Bbommel (Beitrag 1367339)

Und was meinst du hier mit "Hierarchie einhalten"? Ich muss von der abstrakten Basisklasse ableiten - genauso wie du das interface implementieren musst. Das gibt sich doch eigentlich nichts.

Das Interface kann ich aber in verschiedenen Klassen implementieren, die eine beliebige Vererbungs-Hierarchie haben können und im Extremfall lediglich TObject als gemeinsamen Vorfahren haben.

Ich implementiere schon mal gern Interfaces in Forms, Frames oder Datenmodulen (z.B. ILogger-Implementierungen, die Log-Meldungen in Memos oder Datenbanken schreiben). Das wäre mit abstrakten Klassen gar nicht möglich.

Das Problem mit solchen Tutorials ist halt immer, daß es einfach gehalten sein soll, damit man das dahinter stehende Prinzip versteht. In der Regel gibt es bei solch einfachen Fällen dann natürlich auch valide alternative Lösungen. Ein Tutorial ist eben kein Beispiel für eine Killer-Anwendung.

[a.def]

Zitat:

(z.B. ILogger-Implementierungen, die Log-Meldungen in Memos oder Datenbanken schreiben).

Und für so eine einfache Sache braucht man ein kompliziertes Interface?

[DeddyH]

Was soll an einem ILogger-Interface kompliziert sein? Da genügt im einfachsten Fall eine Log-Methode mit einem String-Parameter.

[Bbommel]

Zitat:

Zitat von Uwe Raabe (Beitrag 1367348)

Das Problem mit solchen Tutorials ist halt immer, daß es einfach gehalten sein soll, damit man das dahinter stehende Prinzip versteht. In der Regel gibt es bei solch einfachen Fällen dann natürlich auch valide alternative Lösungen. Ein Tutorial ist eben kein Beispiel für eine Killer-Anwendung.

Joa, daran wird es wohl liegen. Die meisten Sachen, die ich dazu gelesen habe, bauten die Beispiele tatsächlich immer recht einfach auf - ist ja auch klar, um die Syntax und das Grundprinzip zu lernen -, waren dadurch aber eigentlich auch immer mit den abstrakten Klassen "kompatibel".

Insofern hat mich die Diskussion, die sich jetzt hier daraus ergeben hat, tatsächlich weitergebracht. Mal sacken lassen und mal schauen, wann ich demnächst auf ein Problem stoße, wo ich das dann auch mal anwenden kann. Danke euch allen für die Anregungen!

[a.def]

Das geht doch auch viel einfacher ohne ein Interface. Eine einfache Klasse reicht.
Interfaces sind einfach nur komplizierter Spökes den man erst wieder umständlich erlernen muss :P Ich selber komme mit normalen Klassen wunderbar klar und habe noch keine Funktionalität vermisst.

[DeddyH]

Wo ist denn nun der Unterschied zwischen TDings und IDings? Ist I komplizierter als T?

[EWeiss]

Zitat:

Zitat von DeddyH (Beitrag 1367356)

Wo ist denn nun der Unterschied zwischen TDings und IDings? Ist I komplizierter als T?

Nein aber das eine Dings hat ein T und das andere Dings ein I von daher doch etwas kompliziert. LOL ;)
Aber davon ab Interface in DLL's sind eine feine Sache.

Ausgenomen davon wenn da nicht so viele Getter und Setter wären die im Interface mit übernommen werden müssen.

gruss

[stahli]

Eigentlich hatte ich meinen Beitrag vorhin verworfen, aber vielleicht hilft er ja doch noch wem weiter ->

Vielleicht darf ich gleich nochmal auf mein Tutorial verlinken: http://www.delphipraxis.net/183702-i...-factorys.html

Neben der schon erwähnten möglichen Referenzzählung (wenn man es braucht und will) arbeitet man bei Interfaces eher mit Funktionalitäten statt mit konkreten Klassen.

Jedes Objekt kann mehrere Interfaces unterstützen, was bei Verwendung von Basisklassen in Delphi nicht geht.

Ich kann also alle Objekte bewegen, die IMove unterstützen und alle Objekte Loggen, die ILogging unterstützen.
Die konkrete Klasse spielt in dem Moment keine Rolle mehr. Jede im Projekt verwendete Klasse kann kein, eins oder beide Interfaces unterstützen.

Wenn man ohne Interfaces auskommt spricht da überhaupt nichts dagegen.
Der Einsatz von Interfaces erzeugt auch durchaus einigen Mehraufwand und Umstellung beim Umgang mit Objekten.

Bei komplexen Projekten kann sich der aber lohnen, da man u.U. mehr Struktur in das Projekt bekommen und ggf. Klassen später auch leichter austauschen kann. Man ist dann halt nicht von einer bestimmten Basisklasse abhängig.