Visual C# 2012 Grundkurs

Interfaces

Testen Sie unsere 1985 Kurse

10 Tage kostenlos!

Jetzt testen Alle Abonnements anzeigen
Ein Interface in C# beinhaltet Definitionen für eine Gruppe von zusammenhängenden Funktionalitäten, welche von einer Klasse implementiert werden können.

Transkript

In diesem Abschnitt möchte ich Ihnen das Konzept der Interfaces in C# vorstellen. Beginnen wir mit eine Code, den ich schon vorbereitet habe. Der Code enthält eine abstrakte Basisklasse, d.h. das ist eine Klasse, von der Sie kein Objekt anlegen können. Klassen, die von diesen Klassen abgeleitet werden, erben diese Mitgliedsvariable "I" und erben die Implementierung dieser Methode "foo". Aber sie erben auch diese Definitionen, dass Sie nämlich eine Methode namens Bar implementieren müssen und einen Propertynamen namens "Property". Jetzt stellen Sie sich einmal vor, Sie hätten eine Basisklasse eine abstrakte Klasse, keine Mitgliedsvariablen enthalten. Und sie würde keine Methodenimplementierungen enthalten, sondern nur abstrakte Methoden, oder abstrakte Properties. In so einem Fall gibt es ein spezielles Schlüsselwort  so etwas darzustellen. Und dieses Schlüsselwort, das heißt "Interface". Ich kann also jetzt hergehen und eine Klasse definieren, die von diesem Interface abgeleitet ist. Ich muss natürlich das so schreiben. Man spricht aber in dem Fall jetzt nicht von "Ableiten von einem Interface", sondern Interfaces "implementiert" man. Interfaces machen bestimmte Vorgaben, wie etwas auszusehen hat und was eine Klasse zu implementieren hat, nämlich diese Methode "foo" und "bar" und dieses Property. Und die Klassen selbst implementieren das dann. Es gibt dann noch eine Konvention, und zwar, dass die Namen von Interfaces immer mit einem großen "I" anfangen. Insofern gehe ich jetzt einmal her und füge  hier an beiden Stellen ein großes "I" ein und danach sollte eigentlich ein mehr sprechender Name stehen, also das heißt, ein Name, der das Verhalten kennzeichnet, welches mit diesem Interface gemeint ist. In dem Fall belasse ich es aber bei diesem Namen "I my base" und zeige noch eine kleine Feinheit von Visual Studio; nämlich wenn ich jetzt hier rechts auf den Namen des Interfaces klicke, dann gibt es im Kontextmenü einen Punkt "Implement interface" und wenn ich auf den draufklicke, dann erhalte ich eine Rahmenimplementierung aller Methoden und Properties, die mein Interface definiert und die meine Klasse hier eben implementieren muss. Insofern würde ich den Compiler happy machen, indem ich eben schon alles, was ich zu implementieren habe, hier als Rahmen vorliegen habe. Statt dieser Exceptions hier müsste dann irgendwann mal ein Code rein, der auch wirklich etwas Sinnvolles tut. Jetzt stellt sich die Frage: Wenn ich denn schon abstrakte Basis-Klassen habe, die ich für solche Zwecke benutzen kann, warum braucht man dann noch mal etwas Eigenes, ein Interface? Und der Punkt ist, dass Interfaces ja auch konzeptionell ein kleines bisschen etwas anderes sind als Klassen, von denen man ableitet. Das merkt man ja schon an der Begriffsbildung, das man sagt: Man leitet nicht von einem Interface ab, sondern man implementiert ein Interface. Aber es gibt noch einen weiteren interessanten Gesichtspunkt an der Geschichte. Diesen Gesichtspunkt kann ich in diesem Programm hier darstellen. Dieses Programm versucht eine Mehrfach-Vererbung, die ja in C# nicht möglich ist. Ich habe hier eine Klasse "A", die definiert eine virtuelle Methode "foo". Und dann habe ich eine Klasse "B", die von "A" abgeleitet ist, und die überschreibt jetzt diese  Methode und implementiert sie auf ihre Weise. Dann habe ich eine Klasse "C", die überschreibt eben diese Methode "foo" auch; ist auch von "A" abgeleitet und implementiert sie. Jetzt der Versuch, der in C# nicht funktioniert. Ich hätte jetzt eine Klasse "D" und die leitet sich von "B" und "C" ab und würde damit alle Implementierungen, die ich hier definiert habe, erben. Angenommen, C# würde es ermöglichen so ein Konstrukt: Was passiert, wenn ich jetzt ein Objekt der Klasse "D" anlege und versuche, die Methode "foo" aufzurufen; dann habe ich hier einfach das Problem, dass der Compiler nicht weiß, welche der Implementierungen er verwenden soll. Diese Probleme, die zusammen mit der Mehrfachvererbung auftauchen-- auch Probleme des Speicherlayouts, sind nicht vorhanden, wenn wir Interfaces haben. Ein Interface sagt mir, ich habe keine Körper von Methoden, und ich habe keine Mitgliedsvariablen, und deswegen kann auch nichts durcheinander kommen, wenn hier ein Element verwendet wird. Deswegen funktioniert dieser Code, wenn ich statt Klassen Interfaces verwende. Das mache ich jetzt einmal. Ich tausche jetzt überall das Schlüsselwort "Class" gegen das Schlüsselwort "Interface" aus, lösche jetzt diese ganzen Implementierungen hier heraus. Jetzt habe ich es einmal zu viel herausgelöscht. "Foo"-- Also in "A" ist es ja natürlich definiert und in "B" und "C" brauche ich es nicht definieren, weil ich es ja von "A" erbe und weil ich ja keine Implementierungen hinzufügen kann, macht es überhaupt  keinen Sinn, die Methode hier noch mal zu definieren. Jetzt brauche ich natürlich noch eine Implementierung der Methode "foo" und die kann ich jetzt hier in der Klasse "D" erledigen. Eine Implementierung von einem Interface sollte tunlichst auch "Public" sein, damit sie von außen sichtbar ist. Jetzt kann ich diese Methode hier aufrufen und es interessiert den Compiler in keinster Weise, über welchen Weg diese Definition jetzt zu "D" gefunden hat. Es interessiert einfach nur, dass es eine Methode "foo" gibt, die das Programm zu überschreiben hat. Das Ganze funktioniert sogar dann, wenn die beiden Interfaces hier ebenfalls die Methode "foo" implementieren würden und dazu vielleicht noch irgendwelche anderen Methoden. Hier habe ich jetzt absichtlich andere Namen genommen, während der Name "foo" immer gleich bleibt. Das ist alles wunderbar, der Compiler hat damit überhaupt gar keine Probleme. Der Compiler weiß einfach: er braucht genau eine Methode namens "foo", die keine Parameter annimmt und keinen Return-Wert zurückgibt. Soweit zu dem Konzept der Interfaces in C#.

Visual C# 2012 Grundkurs

Schreiben Sie eigene Programme in C# und lernen Sie dazu alle Schlüsselwörter und die meisten Konstrukte kennen, um sicher mit dieser Programmierspreche umzugehen.

7 Std. 1 min (44 Videos)
Derzeit sind keine Feedbacks vorhanden...
 

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!