Interfaces

[3_of_8]

Was ich in Delphi noch gar nicht verstanden habe, ist der Sinn von Interfaces? Wozu sind die da? Braucht man die?

[Khabarakh]

Interfaces sind eine gute Form der "gemilderten" Mehrfachvererbung. Man könnte sagen, deine Klasse erbt zusätzlich von einer rein abstrakten Klasse, also ohne Implementierungen, Felder sind in Interfaces auch nicht erlaubt. Dann gibt es in Delphi noch diese Referenzzählung von Interfaces, aber die hau ich immer raus, bringt einem nur Ärger .

[add] http://www.delphipraxis.net/internal...ct.php?t=32086 [/add]

[3_of_8]

Also ganz abstrakte Klassen? So wie in Java?

[Speedmaster]

Du kannst darin Strukturen Abspeichern, und z.b. 4 Interfaces zusammen benutzen in verschiedenen Kombinationen.

Zumindestens bei einigen Programmen kann man diese auch automatisch einfügen lassen( Also den Inhalt ).
Dies ersparrt schreibarbeit, und setzt bei dem Programm ein gewisses Standart.

Bei .NET kannst du auch interfaces als Parameter übegeben lassen, so kann ein Code aussehen:

Code:

public void Add(IComponent component, string name)
{
    component.Site.Container.Dispose();

    throw new Exception("The method or operation is not implemented.");
}

[schöni]

Hallo 3_of_8!

Und dazu kommt noch, Du kannst mit Interfaces die Möglichkeit schaffen, Deine Anwendung durch Plugins später erweitern zu können, ohne die Anwendung neu übersetzen zu müssen. Die Freeware GExperts für Delphi ist ein bekanntes Beispiel. Und Packages würden ohne die Interfaces wahrscheinlich auch nicht funktionieren.

schöni

[Der_Unwissende]

Zitat:

Also ganz abstrakte Klassen? So wie in Java?

Viel mehr wie Interfaces ganz wie in Java.
Ein Interface ist nah an einer Klasse dran und Grundsätzlich sehr gut geeignet, wenn man OOP benutzen möchte. Ein Interface kapselt in der OOP eine Beschreibung von Methoden, die jedes Objekt, dass das Interface instanziert zur Verfügung stellt. Anders gesagt, du legst ein Interface Form fest, und sagst es hat die Methode berechneFläche.
Nun kannst du Objekte erzeugen (z.B. die Klassen Kreis, Quadrat und Rechteck) und sie so implementieren, dass sie das Interface Form (oder auch viele Interfaces) implementieren. Also weißt du das ein Kreis, ein Quadrat und ein Rechteck eine Methode haben, die berechneFläche heißt. Was sie sonst noch haben ist dir dann vielleicht sogar ganz egal. In diesem sehr einfachen (und stupiden) Beispiel könntest du nun alle Formen nach ihrer Fläche ordnen.

Ok, wenn die Beispiele etwas komplizierter werden, wird der Vorteil auch deutlicher. In Java gibt es zum Beispiel das Interface Comparable. Ein Objekt das Comparable implementiert ist mit einem weiteren (gleichen) Objekt ganz einfach vergleichbar über die Funktion compare, die dir ein int liefert (-1, 0 oder 1, je nachdem was größer ist). Auf dieser Basis kannst du dann eine sehr abstrakte sortierte Liste erzeugen. Die hat dann ein add, dem man ein Comparable übergibt. Sortieren tut die dann, indem sie alle Elemente über compare vergleicht. Das die vergleichbar sind folgt aus der Instanzierung von Comparable.
Hast du nun die Klassen A, B und C, die alle Comparable implementieren, so können die komplett verschieden sein, aber alle haben die Methode compare. Das heißt, deine Liste funktioniert für A's, B's und C's, die gleiche Liste ohne was zu ändern (also eine Liste kann dann nur A's sortiert speichern, oder nur B's oder nur C's, mischen ist da schon schwerer). Aber du hast halt den Vorteil, dass du nicht eine Klasse sortierte Liste für's speichern von A's, eine für B's und eine dritte für C's schreiben musst. Auch das sind noch nicht die wirklich komplexen Beispiele, aber durchaus gute (finde ich). So zahlen sich Interfaces eigentlich schnell aus.

Plug-Ins wurden schon als weiteres Beispiel genannt. Ja, die Basis bei der Idee ist, dass du ein Notify-Listener-Modell implementieren kannst. Das heißt, eine Hauptanwendung verwaltet eine Liste von Listenern (die halt ein best. Interface implementieren). Dazu gibst du dieser Anwendung eine Möglichkeit Listener einzutragen (und auszutragen).
Wenn ein bestimmtes Ereignis auftritt, dann geht die Hauptanwendung diese Liste durch und ruft bei jedem eingetragenen Listener die entsprechende Methode (mit den Parametern des Ereignisses) auf. So kannst du sehr flexibel und einfach auf ein Ereignis reagieren. Und auch sehr leicht dein Programm erweitern. Immerhin musst du kein großartiges Detail der geplanten Funktionalität kennen. Neue Funktionen entstehen (modular) in einer neuen Klasse, die halt als Listener in der Hauptanwendung eingetragen wird und dann auf das (bekannte) Ereignis beliebig reagieren kann.

Hoffe das gibt einen groben Einblick in den Nutzen.

Gruß Der Unwissende

[3_of_8]

Ich bin zu dumm, ich checke gar nix.

Für einen Unwissenden weißt du aber ne ganze Menge.

[Der_Unwissende]

Ach, glaub mir man ist nicht zu dumm.
Mache nebenbei bemerkt meinem Namen alle Ehre, aber lasse ich hier mal nicht zu sehr raushängen. Was man weiß ist halt immer relativ wenig im Verhältnis zu all dem was man nicht weiß. Aber egal, wollen ja hier nicht philosophieren.

Wenn du etwas nicht verstehst, einfach nachfragen. Ich hab ehrlich gesagt auch ein Weilchen gebraucht um mal den Sinn von Interfaces und natürlich auch abstrakten Klassen zu verstehen. Hatte halt mal ohne Objekt Orientierung angefangen (die guten alten Zeiten) und lange deren Vorteile nicht gesehen. Klar, keine Art von Programmierung ist perfekt, aber Objekt Orientierte Programmierung (OOP) ist eigentlich sehr einsteiger freundlich.

Einer der wichtigsten Grundsätze in der OOP besteht halt darin, nur zu zeigen was wirklich wichtig ist (siehe private, protected, public und published). Man versteckt einfach Implementierungsdetails. Genau genommen versucht die OOP das reale Leben auf dem Rechner nachzubilden. Und wenn Menschen etwas recht gut können, dann abstrahieren. Klingt immer alles super kompliziert, ist es aber gar nicht.
Wenn ich mit dir über eine Liste rede, dann kannst du dir doch was drunter vorstellen? Du kennst wahrscheinlich ne Menge Arten von Listen. Mir würden jetzt Listen in Delphi (TStringList, THashedStringList), Listen im realen Leben z.B. Einkaufsliste, Anwesenheitsliste und und und einfallen (gelogen, jetzt müsste ich anfangen zu grübeln).
Nun gut, eine Einkaufsliste ist sicher was anderes als eine Anwesenheitsliste. Doch du kannst beides nicht nur unterscheiden, du kannst auch Gemeinsamkeiten feststellen. So "listen" beide etwas auf, man könnte auch sagen, sie "zählen" etwas auf (auflisten ist für die Definition einer Liste wohl schlecht gewählt). Aber da siehst du es, wir Menschen können sehr intuitiv abstrahieren, der Rechner halt nicht.
Dem musst du schon sagen, was (z.B. Listen) Dinge gemeinsam haben. Da gibt es mehrere Wege. Während die Einkaufsliste nun ja, Artikel speichert, wird die Anwesenheitsliste Anwesenheiten speichern (wie überraschend!). Aber hey, beide speichern etwas. Und beide sind am Anfang leer. Also muss es eine Möglichkeit geben, wie du etwas einträgst. Und es sollte eine Möglichkeit geben, dass du auch wieder liest was drauf steht.
Sagen wir mal Artikel ist eine Klasse (besteht aus Beschreibung und Anzahl) und Anwesenheit ist ne ganz andere Klasse (besteht aus der Person, Name + Vorname).
Ein Interface würde jetzt sowas wie eine Klasse sein, dass ein Methode "füge hinzu" und eine Methode "lese nächsten Eintrag" (z.B.) hat. Das heißt, du sagst : "Wenn es eine Liste ist, dann kann man mit füge hinzu ein Element hinzufügen. Und mit lese nächsten Eintrag einen Eintrag lesen (nil wenn kein weiterer vorhanden)".
Das ist es auch schon. Deine Konkrete Einkaufsliste besteht vielleicht aus einem Array von Artikeln oder einer verketteten oder doppelt verketteten Liste, vollkommen egal (vielleicht ja auch nur zettel und stift), aber sie instanziert (im weitesten Sinne erbt) von Liste. Damit muss sie die Funktionen "füge hinzu" udn "lese nächsten Eintrag" haben und auf ihre Weise implementieren.
Das gleiche gilt für analog für Anwesenheitsliste. Analog heißt hier also, dass z.B. Einkaufsliste alle Artikel in einer doppelt Verketteten Liste von Artikeln speichert. Anwesenheitsliste hingegen alle personen in einem Array[0..100] von Personen. Was die dann machen wenn "füge hinzu" aufgerufen wird, kann wieder ganz verschieden sein. Aber weil sie vom Interface Liste erben, haben sie diese Funktionen und egal was du für eine Liste hast, du kannst diese Funktionen aufrufen.

Die Vorteile kommen dann halt wirklich bei etwas komplizierteren Dingen zu tragen, aber ich hoffe es ist grob klarer geworden?

[3_of_8]

Also ist ein Interface eine grobe Skizzierung einer Klasse.

Und überall, wo sie vorkommt kann man sie auch ersetzen.

[Der_Unwissende]

Hm, kommt der Sache schon nahe. Ein grobe Skizzierung stimmt. Also du möchtest genau genommen nicht nur eine Klasse skizzieren, sondern du möchtest garantieren, dass eine Klasse bestimmte Eigenschaften (oder eher Funktionen) hat.
Ich merk gerade, dass ich einige Dinge vergessen habe. Also machen wir mal weiter, ein Interface ist nur abstrakt. Es gibt keine Implementierung im Interface. Du sagst jede Liste hat eine Funktion die "füge hinzu" heißt. Aber die ist (für das Interface) virtuell und muss von jeder (nicht abstrakten) Klasse implementiert werden. Das heißt, Einkaufsliste muss eine Funktion "füge hinzu" bekommen.

Dann ist noch ein ganz wichtiger (von mir vergessener Teil), du kannst eine Klasse auch auf ihre Vorfahren und Interfaces reduzieren. Ok, ist gerade schlecht ausgedrückt, aber sagen wir deine Einkaufsliste ist eine Klasse, die das Interface Liste implementiert und gleichzeitig auch die Funktion "doFoo" besitzt. Dann sichert dir das Interface die zwei Funktionen "füge hinzu" und "lese nächsten Eintrag" zu. doFoo ist hingegen nur für Einkaufsliste vorhanden.
Der Unterschied wäre nun folgender :

Delphi-Quellcode:

var 
  e1 : TEinkaufsListe;
  e2 : TListe;
begin
  e1 := TEinkaufsListe.Create;

// nicht möglich, da TListe ein Interface ist, keine Klasse
//  e2 := TList.Create; 

// Möglich, aber achtung, e2 wird nur als TListe behandelt!
  e2 := TEinkaufsListe.Create;

  e1.doFoo; // klappt, da e1 TEinkaufsliste
  e1.leseNaechstenEintrag; // muss es geben, da TEinkaufliste TListe implementiert

  e2.leseNaechstenEintrag; // möglich, da jedes TListe-Objekt diese Methode hat
  e2.doFoo; // nicht möglich, da e2 TListe, nur "fuegeHinzu" und "leseNaechstenEintrag" verfuegbar
end;

Wie du hier (schlecht erklärt) siehst, kann man Variablen auch vom Typ des Interface haben. Die Idee hier ist, dass die Funktionen im Interface das einzigste sind was dich interessiert. Ein vielleicht schönes Beispiel wäre TStrings. Hierbei handelt es sich auch nur um ein Interface (behaupte ich einfach mal). Dieses stellt Funktionen zum Einfügen und Suchen von Strings in einer Liste bereit.
TStringList und THashedStringList sind zwei komplett verschiedene Implementierungen. Wenn ich nun eine Funktion mit Parameter List : TStrings habe, kann ich an dieser Stelle sowohl eine TStringList, als auch eine THashedStringlist übergeben. Dass die eine intern irgendwas mit Hashcodes macht, interessiert mich nicht, wenn ich nur alle Einträge in eine Datei schreiben möchte. Mag vielleicht schneller gehen oder was weiß ich, aber kann mir egal sein. Ich will nur wissen, wie ich alle Einträge lesen kann. Für TStrings wäre ein Weg :

Delphi-Quellcode:

procedure writeToFile(list : TStrings);
var i : Integer;
begin
  for i := 0 to list.Count - 1 do 
    begin
      write(list.Strings[i]);
    end; 
end; // procedure writeToFile(list : TStrings);

Den Code kann ich nehmen, und für list ein TStringList, eine THashedStringlist oder was auch immer TStrings implementiert übergeben. Es wird immer funktionieren. Ok, jetzt kann ich es zugegeben, TStrings ist glaube ich eine abstrakte Klasse. Aber Interfaces sind fast das selbe. Wichtig für ein Interface ist halt nur, dass nichts implementiert ist. Das heißt jede Methode ist virtuell/abstract und muss implementiert werden.