Guten Tag

Da ich immer wieder etwas dazulernen will, habe ich mir gedacht ich gucke mir mal die Interfaces genauer da. Jetzt würde ich gerne wissen wozu sie gut sind also wozu man sie benutzt und wie man sie benutzt.

Vielen Dank im Voraus

MfG
Breadsoft

msdn.microsoft.com/en-us/library/28e2e18x.aspx
Ich glaub die MSDN-Bibliothek kann das besser eklären.

Interfaces brauchst du immer dann, wenn eine Klasse verschiedene Vererbbare Eigenschaften besitzen soll. In .Net kann eine Klasse nur eine Basisklasse besitzen, um Probleme von Vielfachvererbung zu vermeiden. Um dennoch ähnliche Funktionalität zu bieten wurden die Interfaces eingeführt (eigentlich ist ein Interface nur eine abstrakte Klasse). In Interfaces können aber keine Member implementiert werden, sondern Interfaces schreiben nur vor, welche Member die Abgeleiteten klassen enthalten müssen. Siehe auch hier.

Zusätzlich gibt es noch speziellere Dinge wie z.B. ComInterfaces
Da brauchst du aber nicht unbedingt ein Interface zu erstellen sondern kannst auch direkt mit Pointern arbeiten. Jedoch ist Interfaces erstellen das übliche.

Hi
man kann sich Interfaces im allgemeinen wirklich als abstrakte Schicht darstellen. Es kommt nicht darauf an, wie etwas implementiert wird, sondern es ist eine vollständige Trennung. Jede Klasse ist nur an den Sinn, der im Interface steckt und die Spezifikation für Fälle gebunden, nicht aber an die konkrete Implementierung. Ein einfaches Beispiel sind zwei ICollection(Of T): LinkedList(Of T) und List(Of T). List(Of T) arbeitet intern mit einem Array, bei einer LinkedList(Of T) zeigt ein Element immer auf das nächste. Bereitgestellt werden hierbei nur einfache Operationen, wie Add, Remove, Contains und Count, die beide Listen zur Verfügung stellen. Wie vorhin erklärt, sind Arrays und verkettete Listen aber komplett unterschiedliche Listen, aber sie funktionieren nach außen hin aus Sicht des Interfaces identisch.

Gruß
~blaze~

Also ist ein Interface nur eine Klasse, jedoch legt nicht der Ersteller sondern der Benutzer fest, was in der jeweiligen Methode/Funktion/Property getan wird??

Nein, ein Interface ist keine Klasse. Interfaces und Klassen sind beides Typen, aber sie haben mehr oder weniger große Unterschiede.
Der Ersteller legt den ZWECK fest, derjenige, der das Interface implementiert letztendlich aber, wie dieser Zweck umgesetzt wird.
Versuche einfach mal folgendes Interfaces abstrakt zu modellieren:
- IFileSystem, eine abstrakte Sicht auf ein Dateisystem unter Verwendung von Uri oder anderen Bezeichnern (muss ja noch nicht unbedingt generalisiert werden), Beispiele sind zum Beispiel Ftp oder das lokale Dateisystem
- IRenderable, kann auf Graphics-Objekte gezeichnet werden, hierbei kann zeichnet jedes IRenderable nur sich selbst, aber konkrete Implementierungen können zum Beispiel eine ICollection(Of IRenderable) besitzen oder nur ein Bild zeichnen (wäre übrigens ein Kompositum)
und überlege dir Beispiele dazu. Außerdem warum gibt es folgendes als Interfaces und warum werden die nicht direkt auf Object definiert?
- IClonable, erzeugt eine Kopie von sich selbst
- IEnumerable(Of T), listet enthaltene Elemente auf



Gruß
~blaze~

Könnte mir das jemand vielleicht mal genauer z.B. an IDisposable oder an einem anderen Beispiel erklären, da ich da noch nicht so ganz durchblicke??

Hab's oben noch mal editiert.
IDisposable zum Beispiel ist auch ein gutes Beispiel. IDisposable hat den Zweck, dass von einem Objekt verwendete Daten freigegeben werden, also ihre Daten gelöscht werden. Die konkrete Implementierung von IDisposable ist zwar Typabhängig, da zum Beispiel Image, Bitmap, Graphics, Icon, aber auch Stream, Control, etc. diesen Typ implementieren. Der Zweck, der mit der Dispose-Methode verbunden wird, ist, dass das Objekt freigegeben wird, auf dem Dispose aufgerufen wird. Somit wird zum Beispiel ein Stream geschlossen oder die einem Bild zugrundeliegenden Daten im Speicher freigegeben. Was genau Dispose aber wirklich tut - es kann auch u.U. nichts tun - ist der Klasse selbst überlassen. Daher ist das eine Abstrakte Sicht auf der Verhalten. Es ist aber in jedem Zusammenhang klar, wann genau Dispose zu verwenden ist, nämlich dann, wenn die Resource nicht mehr verwendbar ist.

Gruß
~blaze~

Ach ja, da du grad IDisposable ansprichst. Microsoft gibt, da eine spezielle Implementierung vor die man einhalten sollte. Also nicht was und wie freigegeben wird sondern wie die Methode implementiert werden sollte. Siehe einfach unten das Beispiel: msdn.microsoft.com/de-de/libra…cs-lang=vb#code-snippet-4
Gleich richtig angewöhnen. Ich musste umstellen

Interfaces werden gerne bei PlugIns verwendet. Man kann damit der PlugIn-Klasse vorschreiben, was sie können muss.
Da gibt's beispielsweise eine Interfaces.dll, die nur die PlugIn-Interfaces enthält. Ein Beispiel wäre:
Interfaces.dll:
(Nebenbei: Interfaces fangen immer mit dem Buchstaben I an. Das klingt jetzt vielleicht unnötig, aber das gesamte .Net-Framework hält sich an diesen Standard und das hilft, Ordnung zu halten.)

Also jedes PlugIn muss einen DisplayName haben. Dann gibt es eine GUID, die zum Identifizieren verwendet wird.
Die Sub OnLoad wird beim Laden des PlugIns ausgeführt. Dann gibt's noch GetStringFromInteger. Das Program, das das PlugIn verwendet, will vom PlugIn nur, dass es einen Integer in einen String verwandelt. Wie das PlugIn das macht, ist dem Programm egal.

Beachte Zeile 2. Das Interface enthält nicht nur die gerade aufgezählten Member, sondern auch die von IDisposable.
Für den Fall, dass ein PlugIn unverwaltete Ressourcen anlegt (z.B. System.Drawing.Bitmap), die verworfen werden müssen, ist das genau das richtige. (Siehe auch Edit am Ende des Posts)

Das wäre ein Beispiel für eine Verwendung:
Das Programm verweist auf die Interfaces.dll


Die PlugIns können jetzt verwendet werden. Hier ein Beispiel für ein PlugIn:
In einer Klassenbibliothek gibt's die Klasse MyPlugIn. Die Klassenbibliothek verweist ebenfalls auf die Interfaces.dll.


So. Ein Aufrufbeispiel für solche PlugIns wäre das hier:
Kommt ebenfalls in die Form1-Klasse.

Das ist das Ergebnis:

Ich habe testweise ein zweites PlugIn hinzugefügt, das die Zahl in hexadezimale Schreibweise umwandelt.

---

Das ist nur ein Beispiel für die Verwendung eines Interfaces.
Genau das selbe würde sich auch mit einer Klasse implementieren lassen:

Das Interface hat aber den Vorteil, dass der PlugIn-Ersteller die PlugIns trotzdem von einer Basisklasse ableiten kann. Wenn er mehrere ähnliche PlugIns erstellt, kann er die Vererbung gezielter ausnutzen.

---

Edit: Weil IDisposable angesprochen wurde:
Ich denke, dass das Interface hier nur eine Vereinheitlichung schaffen soll. Mir würde kein Grund einfallen, irgendwo eine List(Of IDisposable) zu verwenden. Außer man hat einen ResourceDisposer, dem man einen IEnumerable(Of IDisposable) gibt... aber wofür?
Übrigens:
Die korrekte Implementierung wird von Visual Studio direkt eingefügt:

@Niko Ortner Vielen Dank ich habe es jetzt endlich verstanden wie man damit umgeht.

Wenn ich ein Inteface hab und es in eine Klasse benutze baut Visual Studio die Methode selber auf.
Kann ich /darf ich auch eigne Methoden in diese Klasse schreiben?

Natürlich - wieso auch nicht?

Dachte vielleicht gibt es da wieder eine Regel die besagt das nur Methoden aus
dem Inteface benutzt werden dürfen.
Kann ich davon ausgehen das Interfaces eigentlich nur interessant sind wenn man in Gruppen arbeitet oder
wenn eine mehrfach Veerbung realisiert werden soll.
Sehe für mich kein grossen Nutzen ehrlich gesagt.

selbst implementieren musst du sie so gut wie nie.
Ausser - wurde schon gesagt - bei einem Plugin-System.
Und auch bei Remoting.
Achja - auch bei LowLewel-Com-InterOp.
Also gibt sicher noch einige Sachen mehr, aber halt alles ausgewiesene Spezialgebiete.

Normal fährst du mit gut durchdachten Basisklassen wesentlich besser.

---

Nur dass du Interfaces nie brauchst ist wohl ein Witz.
Jede ForEach-Schleife beruht auf dem IEnumerable(Of T) - Interface.
Jede Suche nach Daten basiert auf IComparable(Of T) - oder einem ähnlichen Interface

Gugget auch hier, wenn ihr Zeit zu lesen habt Unterschied zwischen abstrakten Klassen und Interfaces

Die Konversation im link ist gut.
Ich glaub jetzt ist mir das ganze etwas klarer.

Danke für die Info