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.
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?
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 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 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 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

[Assertor]

Zitat von NickelM:

Oder hab ich da was völlig falsch verstanden

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

Gruß Assertor

[stahli]

Die Frage ist ja zeitlos 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

[Phoenix]

Zitat von NickelM:

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

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 von Phoenix:

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.