Was sind Interfaces und wie wendet man sie an? (brauche tut)

[implementation]

Ich sehe in vielen Codes und Beschreibungen immer wieder das Wort Interface.
Doch nirgendwo steht verständlich (!), was genau das ist.
:wiejetzt: Da hilft die Delphi-Hilfe nicht weiter und ich habe auch hier im DP und Google nichts verständliches (!) gefunden.
Kann mir das bitte einmal jemand erklären? :warn:
So oft wie es vorkommt, scheint das thema sehr wichtig zu sein.

Aber bitte kein "Schon mal was von der Suchfunktion gehört"!
Die hat keinen Erfolg gebracht.

[mkinzler]

Ein Interface ist eine Konstrukt, welches einer Klasse sehr ähnelt. Es enthält aber nur abstrakte Methoden und keine Eigenschaften.
Man verwendet es um das Verhalten einer Klasse, also deren Schnittstelle (Interface) zu beschreiben. Es wird dann von diesem Interface zusätzlich zu einer Superklasse vererbt. Da alle Methoden abstrakt sind kann es, zum Unterschied zur Mehrfachvererbung von Klassen, keine Inkonstistenzen der Implementierung kommen.
Interfaces sind auch Grundlage von COM.

[Assertor]

Zitat:

Zitat von implementation

Aber bitte kein "Schon mal was von der Suchfunktion gehört"!
Die hat keinen Erfolg gebracht.

Wir hatten gerade kürzlich eine ähnliche Frage zu Interfaces in anderem Zusammenhang (DLL Klassen) hier in der DP. Also ich konnte das jetzt wiederfinden über die Suche...

http://www.delphipraxis.net/internal...ght=interfaces

Da ist auch ein Link zu einem Tutorial enthalten.

Gruß Assertor

[p80286]

Hallo Assertor,

zu meiner Schande muß ich gestehen, daß ich mit der Suchfunktion auch auf dem Kriegsfuß stehe.
Interface ist ein zu allgemeiner Begriff, als das ohne Zusatzinformation ein "vernünftiges" Suchergebnis zu Stande kommt.
Und für die Zusatzinformationen muß Du Dich eigentlich schon auskennen oder zumindestens einen groben Überblick haben.
Der Hinweis auf das Tutorial geht dann noch irgendwie in der Schlacht um die Einfachheit von VB unter.
Aber brauchbar ist es trotzdem!

Gruß
K-H

[Assertor]

Hallo p80286,

Zitat:

Zitat von p80286

zu meiner Schande muß ich gestehen, daß ich mit der Suchfunktion auch auf dem Kriegsfuß stehe.
Interface ist ein zu allgemeiner Begriff, als das ohne Zusatzinformation ein "vernünftiges" Suchergebnis zu Stande kommt.
Und für die Zusatzinformationen muß Du Dich eigentlich schon auskennen oder zumindestens einen groben Überblick haben.
Der Hinweis auf das Tutorial geht dann noch irgendwie in der Schlacht um die Einfachheit von VB unter.

Zugestanden. Deswegen schrieb ich auch nicht, es sei zu finden, sondern daß wir gerade eine Diskussion in anderem Zusammenhang hatten und ich diese wiederfinden konnte. War also nicht belehrend gemeint.

Zitat:

Zitat von p80286

Aber brauchbar ist es trotzdem!

Das freut mich, ich finde auch, daß es ganz gut und verständlich geschrieben ist.

Gruß Assertor

[NickelM]

Jetzt hab ich mal eine frage dazu...

Hsb ich das richtig verstanden???

Ein Interface ist dazu da, die Kommunikation zwischen Dlls und Exen (also Programmen) zugegeln???

Oder hab ich da was völlig falsch verstanden :oops:

[Assertor]

Zitat:

Zitat von NickelM

Oder hab ich da was völlig falsch verstanden :oops:

Ja, hast Du. Interfaces sind grob gesagt Abstraktion von Klassen, besser Klassen ohne Implementierungen.

Gruß Assertor

[stahli]

Die Frage ist ja zeitlos :wink: daher jetzt mal noch zwei Links zu zwei sehr guten Erklärungen:

http://www.dummzeuch.de/delphi/objec...s/deutsch.html
http://www.dummzeuch.de/delphi/objec...2/deutsch.html

Danke an Thomas :thumb:

[Phoenix]

Zitat:

Zitat von NickelM (Beitrag 830853)

Hsb ich das richtig verstanden???

Ein Interface ist dazu da, die Kommunikation zwischen Dlls und Exen (also Programmen) zugegeln???

Oder hab ich da was völlig falsch verstanden :oops:

Ein Interface ist dazu da, die Kommunikation zwischen unterschiedlichen Klassen zu regeln.
Das kann natürlich zwischen einer .exe und einer DLL passieren, aber auch zwischen Klassen innerhalb einer Exe (oder dll, egal) können sich über Interfaces ansprechen.

Die Idee dahinter ist, das viele unterschiedliche Klassen das gleiche Interface implementieren können.
Konkretes Beispiel: Du hast ein Interface "ILogger", das zum Loggen von Informationen gedacht ist, mit der Methoden "AddLine(message: string)".

Jede Deiner Klassen bekommt nun über den Konstruktor einen ILogger hineingegeben, und merkt sich diesen in einem Feld, und kann nun überall in jeder seiner Methoden mit logger.AddLine() Zeilen in ein Log hinzufügen - ohne das Deine Klasse eine direkte Abhänhigkeit auf das Logging-System besitzt.

Du kannst nun zum Beispiel einen FileLogger oder einen ConsoleLogger implementieren und darüber später entscheiden, ob nun auf die Konsole oder in eine Datei geloggt werden soll. Du kannst auch einen MultiLogger implementieren, der sich intern einen File- und einen Console-Logger hält und bei AddLine die Zeile auf alle internen ILogger verteilt.

Du bist also viel Flexibler wenn Du das Logging anpassen/erweitern willst ohne das Du jede einzelne Klasse die loggt anfassen musst.

[Dejan Vu]

Zitat:

Zitat von Phoenix (Beitrag 1260371)

Die Idee dahinter ist, das viele unterschiedliche Klassen das gleiche Interface implementieren können.

Das schafft man auch mit einer abstrakten Basisklasse.

Interfaces sind Spezifikationen ohne jegliche Implementierung. Während bei einer abstrakten Basisklasse noch Implementierungen bzw. Geschäftslogik enthalten sein können, definieren Interfaces ausschließlich die Außendarstellung einer Klasse, sie sind also so etwas wie ein Vertrag, den eine Klasse einhalten muss, um vom Anwender des Interfaces verwendet werden zu können.

Interfaces verbergen die Implementierung, d.h. Du kannst eine Klasse unsichtbar machen, sodass Sie nie direkt instantiiert werden kann. Über eine Factorymethode zwingst Du den Anwender dann, bei Bedarf eine Instanz kontrolliert zu instantiieren, z.B. um bestimmte und notwendige Eigenschaften vorzubelegen. Das geht mit einer Klasse so nicht.

Interfaces beschreiben, salopp ausgedrückt, was eine Klasse alles (an Eigenschaften) hat und (über Methoden) können muss, aber nicht wie. Eine Klasse macht das im 'interface' Teil zwar auch, aber Du kannst die Klasse nicht ohne Implementierung weitergeben.

Als Programmierpattern haben wir uns (in C#) angewöhnt, Klassen stets als internal zu deklarieren, deren Interface (also die Eigenschaften und Methoden für den korrekten Umgang) als public. Die Klasse definiert wesentlich mehr Methoden als das Interface, aber nicht 'nach außen'. 'Außen' ist hier jede andere Assembly.

Das geht -glaube ich- so nicht in Delphi. Es gibt keinen Zugriffsmodifizierer (private, protected, public) auf Typebene. Leider.

[Sir Rufo]

Ein entschiedener Unterschied ist, dass eine Klasse mehrere Interfaces implementieren kann, aber nicht von mehreren Klassen erben kann.

Das funktioniert nicht

Delphi-Quellcode:

type
  TEsel = class abstract
  end;

  THund = class abstract
  end;

  TKatze = class abstract
  end;

  THahn = class abstract
  end;

  TBremerStadtmusikanten = class( TEsel, THund, TKatze, THahn ) // das geht nicht!
  end;

aber mit Interfaces geht es

Delphi-Quellcode:

type
  IEsel = interface
  end;

  IHund = interface
  end;

  IKatze = interface
  end;

  IHahn = interface
  end;

  TBremerStadtmusikanten = class( TInterfacedObject, IEsel, IHund, IKatze, IHahn )
  end;

[Dejan Vu]

Aber sind die Bremerstadtmusikanten nicht eher ein Stack? :mrgreen:

[mkinzler]

Zitat:

Das schafft man auch mit einer abstrakten Basisklasse.

Aber dann könnte eine Klasse nur eine Aufgabe erfüllen/Rolle. Bei Interfaces beliebig viele.

Zitat:

Du kannst eine Klasse unsichtbar machen, sodass Sie nie direkt instantiiert werden kann.

Das mit dem nicht instantiieren gilt auch in vielen anderen Sprachen für abstrakte Klassen ( in Delphi nur in neueren Versionen; in Delphi sind nur Methoden abstrakt).
Aber ich verstehe nicht, was du mit unsichtbar meinst.

Zitat:

Das geht -glaube ich- so nicht in Delphi. Es gibt keinen Zugriffsmodifizierer (private, protected, public) auf Typebene. Leider.

Innerhalb eine Klasse schon. Und wenn du einen Typ im Implementation-Teil deklarierst ist er auch nur in der Unit sichtbar.
Standardmässig gelten die Modifizierer aber nicht innerhalb der Unit, höchstens du deklarierst sie als strict.

[Sir Rufo]

Zitat:

Zitat von Dejan Vu (Beitrag 1260384)

Aber sind die Bremerstadtmusikanten nicht eher ein Stack? :mrgreen:

Historisch gesehen waren die zuerst ein Heap und haben sich dann zu einem Stack organisiert :mrgreen:

[Lemmy]

Zitat:

Zitat von Dejan Vu (Beitrag 1260374)

Zitat:

Zitat von Phoenix (Beitrag 1260371)

Die Idee dahinter ist, das viele unterschiedliche Klassen das gleiche Interface implementieren können.

Das schafft man auch mit einer abstrakten Basisklasse.

nur wenn alle Klassen von der abstrakten Basisklasse abgeleitet werden können. Wenn nicht, dann wirfst Du entweder OOP-Prinzipien über Bord oder machst Dein Klassenmodell künstlich komplexer als es sein muss. Und das sehe ich als großen Vorteil von Interfaces an: Ich kann gleiches Verhalten in unterschiedliche KLassen bzw. Klassenmodelle "injizieren", ohne dass diese voneinander wissen müssen. Und damit kannst Du dann Code wirklich wieder verwenden...

[Sir Rufo]

Zitat:

Zitat von Lemmy (Beitrag 1260388)

Zitat:

Zitat von Dejan Vu (Beitrag 1260374)

Zitat:

Zitat von Phoenix (Beitrag 1260371)

Die Idee dahinter ist, das viele unterschiedliche Klassen das gleiche Interface implementieren können.

Das schafft man auch mit einer abstrakten Basisklasse.

nur wenn alle Klassen von der abstrakten Basisklasse abgeleitet werden können. Wenn nicht, dann wirfst Du entweder OOP-Prinzipien über Bord oder machst Dein Klassenmodell künstlich komplexer als es sein muss. Und das sehe ich als großen Vorteil von Interfaces an: Ich kann gleiches Verhalten in unterschiedliche KLassen bzw. Klassenmodelle "injizieren", ohne dass diese voneinander wissen müssen. Und damit kannst Du dann Code wirklich wieder verwenden...

Das Beispiel von Phoenix kann man aber sehr gut auch mit einer abstrakten Klasse erreichen, darum ist der Einwand berechtigt, weil damit nicht wirklich der Vorteil/Unterschied/die Wesensart von Interfaces dargestellt wird.

[Dejan Vu]

Zitat:

Zitat von mkinzler (Beitrag 1260385)

Zitat:

Das schafft man auch mit einer abstrakten Basisklasse.

Aber dann könnte eine Klasse nur eine Aufgabe erfüllen/Rolle. Bei Interfaces beliebig viele.

Da grübele ich jetzt widerum, was Du genau meinst: Was meinst Du da mit 'eine Aufgabe' vs. 'beliebig viele'?

Zitat:

Das mit dem nicht instantiieren gilt auch in vielen anderen Sprachen für abstrakte Klassen ( in Delphi nur in neueren Versionen; in Delphi sind nur Methoden abstrakt).
Aber ich verstehe nicht, was du mit unsichtbar meinst.

Erklärung: Ich möchte nicht, das meine Klasse (keine abstrakte) direkt instantiiert wird. Ich verlange, das sie über eine Factory instantiiert wird. Daher muss ich die Klasse verbergen, denn sie kann ja u.U. mehr, als ich nach außen hin preisgeben will. Wenn Du also die Unit einbindest (Assemblies gibts ja leider nicht), dann siehst Du nur das Interface und die Factory.

Delphi-Quellcode:

Unit myAssembly;
interface
Type
  IMyInterface = interface...
  IInterface1 = interface (IMyInterface)...
  IInterface2 = interface (IMyInterface)

function Factory<T : IMyInterface>() : T; // geht das? 
implementation
Type
  TClass1 : class (TInterfacedObject, IInterface1)
  end;

  TClass2 : class (TInterfacedObject, IInterface2)
  end;

...
end.

Hier sind die Klassen 'TClass1' und 'TClass2' unsichtbar.

Zitat:

Und das sehe ich als großen Vorteil von Interfaces an: Ich kann gleiches Verhalten in unterschiedliche Klassen bzw. Klassenmodelle "injizieren", ohne dass diese voneinander wissen müssen. Und damit kannst Du dann Code wirklich wieder verwenden...

Absolut, ich habe ja nicht gegen Interfaces gewettert.

[Sir Rufo]

@Dejan Vu

Ja, das geht so mit den Factories (allerdings nicht mit den Generics in einer simplen Funktion)

[Lemmy]

Zitat:

Zitat von Dejan Vu (Beitrag 1260392)

Zitat:

Und das sehe ich als großen Vorteil von Interfaces an: Ich kann gleiches Verhalten in unterschiedliche Klassen bzw. Klassenmodelle "injizieren", ohne dass diese voneinander wissen müssen. Und damit kannst Du dann Code wirklich wieder verwenden...

Absolut, ich habe ja nicht gegen Interfaces gewettert.

sorry, ich hatte einen Knoten im Hirn, ich dachte bei abstrakter Basisklasse an das hier:

Delphi-Quellcode:

TLogger = class()
---
end;

TPerson = class(TLogger)
---