... so, jetzt schreibe ich nicht auf dem Handy und versuche es nochmal klarzustellen:
Der Begriff "Schnittstellen" ist nicht eindeutig, sondern wird für verschiedene Aspekte in Java verwendet.
1) Für die ...Kontaktstelle... einer Klasse nach außen. Wenn du dich schonmal mit der Konzeption von Klassen und dem Begriff der Datenkapselung beschäftigt hast, dann weißt du, dass man nicht alles nach außen trägt, was die Klasse intern an Informationen hat. Man hat halt Daten und Methoden, die private sind (also nicht von außen sichtbar sind) und Methoden (normalerweise keine Daten) die public sind (protected und ähnliches lass ich jetzt mal weg). Alles, was public ist, ist von außen - also von anderen Klassen her - sichtbar. Das nennt man die Schnittstelle einer Klasse.
EinBeispiel: Stell dir vor, du hast eine Klasse Fußballspieler. Die Schnittstelle nach außen wären Methoden wie: passen(), schießen(), ausDemAbseitsGehen(), hatBall(), setTrikotNummer(int nummer) usw.
Diese Methoden, mit denen du ein Objekt dieser Klasse manipulieren kannst, sind in der Regel öffentlich (public) und stelle in ihrer Gesamtheit die Schnittstelle der Klasse dar. Wie die Klasse intern funktioniert, welche Datenelemente (z.B. int trikotNummer, boolean hatBall etc.) sie hat und vielleicht welche internen Methoden sie verwendet (z.B. boolean isInDerMannschaft, void passeBallAn(int spielerNummer)) ist intern und ist von außen nicht sichbar (diese Elemente sind private).
Aber... Java kennt auch eine Programmiertechnik, welche Interface (wörtlich übersetzt "Schnittstelle") heißt. Diese Technik funktioniert so, dass in einem Interface bestimmte Methoden deklariert werden (also Name, Rückgabewert und Parameter dieser Methoden werden benannt), aber das ist schon alles. Der INHALT dieser Methoden wird nicht im Interface programmiert. Der Clou ist: jede Klasse, die dieses Interface implementiert ist verpflichtet, diese inhaltliche Logik, dann auch konkret bei sich einzubauen. Wenn also ein Interface eine Methode bla() verlangt, dann muss die implementierende Klasse entsprechend eine Methode bla() haben.
2) Wozu das Ganze? Wenn du eine Klasse verwendest, die ein Interface xyz implementiert, welches eine Methode bla() verlangt, dann kannst du auch sicher sein, dass diese Klasse jene Methode hat (ansonsten könntest du das Prog nicht kompilieren, es würde einen Compilerfehler geben). Das wiederum ist extrem wichtig, wenn du mit Polymorphie arbeitest.
Deswegen sprach ich in meinem ersten Post auch von "Vertrag". Eine Klasse, die ein Interface implementiert verpflichtet sich verbindlich, dessen Methoden "mit Leben" auszufüllen. Wenn du weißt, dass eine Klasse dieses Interface implementiert, dann kannst du absolut sicher sein, dass die Methoden dieses Interfaces auch verwenden kannst!!!
Falls du dich schon mit Polymorphie beschäftigt hast: Du kannst halt auch eine Variable erstellen, die nicht auf einer Klasse basiert, sondern auf einem Interface. Dieser Variablen kannst du beliebige Inhalte, auch von anderen Klassen zuweisen, hauptsache, sie implementieren das entsprechende Interface. Sie haben sich ja "verpflichtet" dessen Methoden zu implementieren...
Der Sinn des ganzen (wenn man es auf einer abstrakten Ebene betrachtet) ist, dass über Interfaces bestimmte Eigenschaften für verschiedene Klassen verfügbar gemacht werden können, die ansonsten nix miteinander zu tun haben. Deswegen verwendet man für die Benennung von Interfaces am Besten Adjektive (also Eigenschaften). Ein Interface "alkoholisierbar" hat zB eine Eigenschaft "isBetrunken". Für jede Klasse, die dieses Interface implementiert, kann also geprüft werden, ob Objekte, welche von dieser Klasse abgeleitet werden, besoffen sind. Diese Klassen können zB vom Typ "Person", "Chef" oder meinetwegen auch "Auto" sein. Ob Letzteres Sinn macht, muss der Programmierer wissen (ich würde es bezweifeln).
