| 

.NET C# Java Javascript Exception

4
Abstrakte Klassen und Interfaces lassen sich nutzen, um Schnittstellen vorzudefinieren. Schnittstellen beschränken sich dabei auf die definition von Signaturen, wobei in den In terfaces static-final-Variablen definiert werden dürfen. Abstrakte Klassen müssen sich hingegen nicht auf die Definitionen der Signaturen beschränken, sondern definieren das grundlegende Gerüst mitsamt ausgewählten Funktionalitäten, wobei die Klasse benutzerdefiniert erweitert und vererbt werden kann. Was ist aber technisch der hauptunterschied? Ist es wirklich der, das eine Klasse "vererbt" werden, und ein Interface "implementiert" werden muss oder gibt es weitere Unterschiede, die es zu beachten gibt?
News:
14.04.2012
hasmat 41 2
1 Antwort
4
Was ist aber technisch der Hauptunterschied?

Kommt drauf an, wie Du "technisch" verstehst. In C++ z.B. gibt es kein eigenes Sprachkonstrukt für Interfaces. Sie werden dort als abstrakte Klassen dargestellt, die nur abstrakte ("pure virtual", um genau zu sein) Methoden haben. Aus dem Blickwinkel sind Interfaces dort nur ein technischer Spezialfall von abstrakten Klassen.
In Java kommt als technischer Unterschied hinzu, dass eine Klasse nur von einer anderen Klasse erben darf, aber beliebig viele Interfaces implementieren kann. Soweit ich weiß, steht dahinter eine bewußte Design-Entscheidung der Java-Entwickler, um Probleme zu vermeiden, die die Mehrfachvererbung sonst mit sich bringen kann (siehe z.B. das Diamond-Problem). Außerdem sind nested classes nur in Klassen, nicht aber in Interfaces möglich.
Ich finde, der wesentliche Unterschied liegt aber eher in der Bedeutung als in der Technik. Eine Schnittstelle definiert einen Vertrag - rein technisch gesehen die Zusage, Methoden mit den vorgegebenen Signaturen bereitzustellen, darüberhinaus aber auch inhaltlich, die Methoden im Sinner einer bestimmten (durch die Dokumentation vorgegebenen) Bedeutung zu implementieren (die Signaturen von add() und multiply() unterscheiden sich nicht, aber das erwartete Ergebnis schon).
Von einer Klasse zu erben hingegen bedeutet, ein schon vorgegebenes Verhalten zu übernehmen und zu ergänzen oder zu modifizieren. Die erbende Klasse übernimmt dann nicht nur die Zusage, den Vertrag zu erfüllen, der durch die Methoden-Signaturen gegeben ist, sondern auch schon das "Wie" der Erfüllung dieses Vertrages.
Eine abstrakte Klasse schließlich ist eine Art Zwitter: man erbt einerseits Verhalten, andererseits wirken die abstrakten Methoden wie ein Interface. Das kann auf unterschiedliche Weise eingesetzt werden: zum Beispiel kann eine abstrakte Klasse ein Interface schon zum Teil implementieren und nur noch ein paar wichtige Stellen als TODOs offenlassen. Das ist die Idee hinter AbstractList und anderen Abstract*-Basisklassen im JDK. Die abstrakten Methoden sind in diesem Fall public. Es wäre aber auch denkbar, dass die abstrakte Klasse ihre Außensicht (also die public-Methoden) schon komplett selbst implementiert, sich dafür aber intern auf die "Zuarbeit" der ableitenden Klassen verläßt und zu diesem Zweck protected abstrakte Methoden vorsieht. Das passiert z.B. beim Einsatz des Template-Musters.

Noch eine Bemerkung am Rande: Du erwähnst die static-final-Felder. Ich muß gestehen, dass mir kein wirklich sinnvoller Einsatz dieses Features bekannt ist, schon gar keiner, der mit der Idee eines einzuhaltenden Vertrages konform geht. Hingegen gibt es "dank" dieser Felder ein Anti-Pattern, nämlich Constant Interface, zu dessen Vermeidung ich an dieser Stelle raten möchte.
15.04.2012
Matthias Hlawatsch 13,2k 4 9

Stelle deine Java-Frage jetzt!