Mal eine kurze Einführung
Was eine Klasse ist, sollte ungefähr klar sein, man könnte sie als einen "Bauplan" für eine bestimmte Art von Objekten ansehen. Objekte sind sinnvolle Einheiten von Daten (andere Objekte und - in Sprachen wie C++ und Java - primitive Typen) und Verhalten (Methoden).
Konstruktor: Konstruktoren sind eine besondere Art von "Methoden" zur Erzeugung von Objekten. Man kann sie nicht an einem Objekt aufrufen, denn man hat ja noch keins, sondern will erst eins erzeugen. Außerdem muss ja erst einmal Speicher für das Objekt reserviert werden. In "altmodischen" Sprachen musste man das selber tun (etwa mit der Funktion malloc() in C). Moderne Sprachen "wissen" anhand der Klassendefinition, welcher Speicher benörigt wird und reservieren ihn automatisch. Damit ist das neue Objekt aber noch nicht "fertig", es müssen erst einmal sinnvolle Werte gesetzt werden, und das macht man im Konstruktor. Danach wird das Objekt "betriebsbereit" zurückgegeben. Für Konstruktoren gelten im Gegensatz zu den Methoden einige Sonderregeln, z.B. dass sie nicht vererbt werden.
Interface: Sprachen wie C++ haben mit Mehrfachvererbung herumexperimentiert, ein Amphibienfahrzeug konnte also die Eigenschaften von Schiff und Auto erben. Hört sich gut an, führte aber in der Praxis zu Problemen. Java hat deshalb Einfachvererbung (nur eine Elternklasse). Diese Vererbunghierarchie ist aber wiederum zu starr: Oft wünschte man sich sagen zu können: Die Klasse erbt von dieser Klasse und kann aber auch das und das. Diese "Befähigungsnachweise" oder auch "Garantien" nennt man Interfaces. Wenn eine Klasse ein Interface "implementiert" heißt das, dass die Objekte der Klasse die im Interface angegeben Methoden besitzen. Beispiel Comparable: Egal, in welcher Vererbungshierarchie man gerade ist, wenn eine Klasse sagt, dass sie Comparable implementiert, sichert sie zu, dass ihre Objekte eine compareTo-Methode besitzen (so, wie im Interface Comparable spezifiziert), mit der sie untereinander verglichen werden können. Jetzt kann man z.B. eine Methode zum Sortieren von Listen schreiben, der völlig egal ist, welche Klasse die Listenelemente haben: Elefanten, komplexe Zahlen, chemische Elemente... solange diese Klassen nur das Interface Comparable implementieren, und demnach eine compareTo Methode besitzen, denn das ist alles, was zum Sortieren nötig ist. Wie diese compareTo-Methode definiert ist, ist Sache der Klassen (Elefanten vergleicht man sicher anders als komplexe Zahlen), aber für das funktionieren der Sortierung ist das irrelevant.
Abstrakte Methoden: Wenn man Fälle hat, wo man weiß, dass es bestimmte Methoden "gibt" und was sie "bedeuten", aber man noch keine konkrete Implementierung bereitstellen kann. Etwa in der Mathematik, wo es abstrakte Gebilde wie Gruppen, Ringe und Körper gibt. Ein Ring ist z.B. eine Struktur, auf der zwei Operationen "Addition" und "Multiplikation" definiert sind. Wie die Operationen aussehen, weiß ich nicht, ich kann aber trotzdem eine Klasse Ring mit den abstrakten Methoden "plus" und "mal" schreiben und basierend auf diesen "noch nicht definierten" Methoden bereits andere Funktionalität bereitstellen z.B. könnte ich bereits Potenzieren auf Basis wiederholter Multiplikation definieren. Wenn ich nun konkrete Unterklassen von "Ring" bilde, etwa natürliche Zahlen, komplexe Zahlen, quadratische Matrizen oder Polynome, kann ich dort jeweils die Definitionen für plus und mal "nachliefern". Das in "Ring" bereits definierte Potenzieren usw. stände dann sofort zur Verfügung (es muss also nicht in jeder Klasse einzeln programmiert werden). Abstrakte Methoden ähneln ein wenig Interfaces, auch sie geben eine "Garantie": "Ich habe zwar noch keine konkrete Definition, aber so wird die Methode später mal heißen, die und die Argumente besitzen und das und das zurückliefern".
