Interfaces beziehungsweise Schnittstellen bezeichnen in der Computerwelt eine Menge verschiedener Dinge. Es gibt eine Benutzerschnittstelle, Softwareschnittstellen, Maschinenschnittstellen und mehr. Uns interessiert das Interface, wie es in der objekt-orientierten Programmierung genutzt wird. Schnittstellen dienen dort als zuverlässige Definition der verfügbaren Methoden, Eigenschaften oder Ereignisse für eine oder mehrere Klassen, welche diese tatsächlich definieren.<\/b><\/p>\n
Auf diese Weise kann man sich beim Programmieren “gegen” eine Schnittstelle darauf verlassen, dass die Klasse, welche die Schnittstelle implementiert, auch die dort definierten Methoden, Eigenschaften, Ereignisse und Indexer enthält (Indexer haben Sie im Rahmen dieses Magazins noch nicht kennen gelernt, daher gehen wir in diesem Artikel nicht auf diese Elemente ein).<\/p>\n
Wozu aber sollte man überhaupt verschiedene Klassen programmieren, die alle die gleichen Methoden, Eigenschaften oder Ereignisse enthalten und somit die Schnittstelle implementieren Ein Grund ist, dass Sie nur einmal lernen möchten, wie etwas funktioniert (die in der Schnittstelle definierten Elemente), die Implementierung jedoch je nach Anwendungsfall variieren kann.<\/p>\n
Stellen Sie sich das Anziehen oder Lösen einer Schraube vor: Sie verwenden den für die Schraube passenden Schraubendreher, zum Beispiel einen Kreuzschlitz- oder einen Längsschlitz-Schraubendreher. Nun haben beide Schraubendreher vielleicht unterschiedliche Griffe, wodurch Sie jeweils anders greifen müssen. Nun stellen Sie sich einen Schraubendreher mit austauschbaren Bits vor: Die (Benutzer-)Schnittstelle ist der Griff, mit dem Sie den Schraubendreher nach links oder rechts drehen können, aber je nach Schraube verwenden Sie ein anderes Bit, um diese anzuziehen oder zu lösen. Sie kennen also die beiden Methoden der Schnittstelle, also nach links und nach rechts drehen, und können verschiedene Implementierungen nutzen – also etwa ein Bit für Kreuzschlitz- und ein anderes für Längsschlitz-Schrauben. Genau genommen ist auch die Schnittstelle zwischen dem Schraubendreher und dem Bit ein Interface – wir haben also gleich ein doppeltes Beispiel für ein Interface.<\/p>\n
Genau das Gleiche kann in der Software-Welt geschehen: Sie möchten beispielsweise eine E-Mail verschicken und dazu einem Objekt den Empfänger, den Betreff und den Inhalt übergeben (die Eigenschaften) und die Mail dann mit der Senden<\/b>-Methode abschicken. Welcher Mechanismus dahinter steckt, soll für den Aufruf uninteressant sein – es könnte sich um die Programmierung von Outlook handeln, um die Mail mit diesem Programm zu versenden, aber vielleicht verwendet eine andere Implementierung nicht Outlook, sondern eine speziell für den Versand von E-Mails vorgesehene SMTP-Schnittstelle.<\/p>\nBeispiel: Daten abrufen<\/h2>\n
Oder, was in diesem Magazin auch bereits das eine oder andere Mal beschrieben wurde: Sie möchten ein Objekt mit Daten füllen, also etwa ein Kunden-Objekt mit den Eigenschaften KundeID<\/b>, Vorname <\/b>und Nachname<\/b>. Wenn Sie mit der Programmierung beginnen, sollen die Daten aus einer Access-Datenbank kommen. Aber vielleicht wechseln Sie demnächst zu einer SQL Server-Datenbank Oder lesen die Daten aus einer XML-Datei ein Dann benötigen Sie in jedem Fall unterschiedliche Implementierungen der Methoden, da der Zugriff auf die Daten ja nicht auf die gleiche Art erfolgt.<\/p>\nVerschiedene Methoden oder verschiedene Implementierungen<\/h2>\n
Natürlich könnten Sie, um beim Beispiel des Abrufs von Daten aus verschiedenartigen Datenquellen zu bleiben, für jeden Zugriff eine andere Methode implementieren – also beispielsweise HoleKundeAccess<\/b>, HoleKundeSQLServer <\/b>oder HoleKundeXML<\/b>. Dann müssten Sie allerdings auch irgendwo eine Bedingung unterbringen, die prüft, welche der Methoden zum Abrufen eines Kunden-Objekts aus einer der verschiedenen Datenquellen zum Einsatz kommen soll.<\/p>\n
In der Objektorientierung soll dies jedoch anders ablaufen. Hier definieren Sie jeweils eine Klasse mit Methoden für den Zugriff auf die Daten der verschiedenen Datenquellen, also etwa Access, SQL Server oder XML. Dort sollen natürlich für jede Datenquellenart noch weitere Eigenschaften, Methoden oder auch Ereignisse definiert werden. Würden Sie diese alle in einer Klasse unterbringen, hätten Sie erstens eine recht unübersichtliche Anhäufung von Elementen. Außerdem gäbe es keine Prüfung, ob tatsächlich alle Methoden, Eigenschaften und Ereignisse für die verschiedenen Datenquellen definiert wurden.<\/p>\n
Wenn Sie hingegen eine Schnittstelle beziehungsweise ein Interface definieren und für jede Datenquellenart eine eigene Klasse erstellen, welche die in der Interface-Klasse definierten Methoden, Eigenschaften und Ereignisse implementiert, erhalten Sie automatisch eine Prüfung, ob alle benötigten Elemente vorliegen. Dazu müssen Sie beim Programmieren der Klasse nur angeben, welche Schnittstelle diese implementiert.<\/p>\n
Möchten Sie weiterlesen? Dann lösen Sie Ihr Ticket!<\/span>
\nHier geht es zur Bestellung des Jahresabonnements des Magazins Visual Basic Entwickler<\/strong>:<\/span>
\nZur Bestellung ...<\/a><\/span>
\nDanach greifen Sie sofort auf alle rund 200 Artikel<\/strong> unseres Angebots zu - auch auf diesen hier!<\/span>
\nOder haben Sie bereits Zugangsdaten? Dann loggen Sie sich gleich hier ein:<\/span><\/p>\n<\/div>\n\n\t\n\t