Java Abstrakte Methoden vs Interfaces

[Danny787]

Ich hab bald meine OOP Prüfung und mir sind noch ein paar Grundlagen noch nicht so ganz klar. Wie man dem Titel schon entnehmen kann stellt sich mir die Frage , wann es sich besser anbietet, eine abstrakte Methode bzw. ein Interface zu verwenden.
Wäre nett, wenn ihr ein konkretes Anwendungsbeispiel nennen könnten, welches den Unterschied verdeutlicht.

Danke schon mal im voraus

 

[Dr. Greg House]

Ein Interface ist einfach nur dazu da, die Mehrfachvererbung so gut wie möglich zu realisieren, ohne dass das von der eigentlichen Mehrfachvererbung verursachte "Diamond-Problem" auftritt.
http://de.wikipedia.org/wiki/Diamond-Problem

 

[SteveP]

Hi,

es gibt zwischen abstrakten Methoden (abstrakten Klassen) und Interfaces einen großen Unterschied. Und zwar können abstrakte Klassen Methoden und Attribute enthalten. Hier können die Methoden auch schon implementiert werden, also mit "Inhalt versehen werden". Um von einer abstrakten Klasse zu erben, verwendest du das Schlüsselwort "extends".

Ein Interface dagegen hat nur abstrakte Methoden und garantiert, dass du auf gewisse Methoden zugreifen kannst. Die Implementierung selbst findet aber erst in der Klasse statt, die das Interface implementiert. Bei Interfaces wird das Schlüsselwort "implements" verwendet.

Eine Klasse kann zu dem nur von einer abstrakten Klasse erben, aber von mehreren Interfaces.


Grüße
Stephan

 

[timurinamanu]

also:
Bei einem Interface muss man alle Methoden implementieren.
Beim Interface gibt es nur Methoden keine Variablen.
Eine Klasse kann mehrere Interfaces haben.

Bei Abstrakten Klassen kann man die Methoden implementieren muss aber nicht.
Eine Klasse darf immer nur eine Superklasse haben.
Abstrakte Klassen können Variablen haben.

Anwendungen:
1.Interface:
Z.B. Du sollst ein Verhalten darstellen, nehmen wir z.B. Säugetiere
Interface: Säugetiere
Methoden:
geräuschmachen()
essen()
bewegen()
....


2.abstrakte Klasse:
Klasse Tier:
Name
Gewicht
identifizieren()
geräuschmachen()

so nun kann man von dieser superklasse diverse Tiere ableiten
z.b.
Affe extends Tier
Fellfarbe
klettern()
...

man kanns natürlich auch kombinieren:
Affe extends tier implements säugetier
Hier wäre ein Interface und eine abstrakte Klasse Sinnvoll, da jedes Säugetier diese Verhalten aufzeigt.

Ich hoffe, das hilft dir, falls nicht, kannst ja fragen
mfg

 

[captmcneil]

Hm, mit so Aussagen wie "Interfaces haben keine Variablen, nur Methoden" wär ich vorsichtig, solche Sachen sind ziemlich abhängig von der Programmiersprache

Gerade in Java kann man z.B. static final-Variablen in Interfaces definieren - wobei man wieder argumentieren könnte, dass das im Grunde Konstanten sind.

... stellt sich mir die Frage , wann es sich besser anbietet, eine abstrakte Methode bzw. ein Interface zu verwenden.

In den 2 Posts weiter oben stand eigentlich schon alles grundlegende gut erklärt. Etwas tiefergehend ist halt die Bedeutung von Interfaces:

Interfaces haben ja im Grunde "nur" den Sinn, dass sich eine Klasse - platt gesagt - auf das Interface casten lässt, und man dann die Methoden aufrufen kann. Ein Objekt einer Klasse, die z.B. das Interface "List" implementiert, kann man also auf "List" casten.

In größeren Projekten wirst Du feststellen, dass Methoden als Parameter tendenziell Interfaces wollen oder Interfaces zurückgeben. Das hat den Hintergrund, dass man mit Interfaces viel freier hantieren kann, da ja, wie gesagt, eine Klasse beliebig viele Interfaces haben kann, aber nur eine Oberklasse. Desweiteren will eine Methode auf ihre Parameter eigentlich nur irgendwelche Befehle aufrufen, und die werden über das Interface bekannt gemacht.

Ein Beispiel hierzu ist das Collection-Framework in Java: es ist guter Stil, wenn eine Methode, die z.B. eine Auflistung an Strings benötigt, eine Deklaration etwa der folgenden Art hat:

void myFunction(List<String> someStrings) {...

oder

void myFunction(Collection<String> someStrings) {...

und nicht etwa:

void myFunction(AbstractList<String> someStrings) {...

oder

void myFunction(ArrayList<String> someStrings) {...

List ist ein Interface, und für "myFunction" sollte es auch nur wichtig sein, dass der Parameter eine Liste ist. Wie genau die Liste implementiert ist (also ob es eine ArrayList, LinkedList, etc. ist), ist für den Datenaustausch zwischen Klassen und Methoden in der Regel unwichtig.

Interfaces sind auch wichtig für die Gliederung von Komponenten: Wenn Du eine Programmkomponente, beispielsweise ein Java-Package, entwickelt hast, und diese an andere weitergibst, wirst Du in diesem Sinne auch eher nur Interfaces nach außen bekannt geben, und keine (abstrakten) Klassen, da diese Code beinhalten. D.h. öffentliche Methoden aus deinem Softwarepaket sollten Interfaces zurückgeben, oder Interfaces als Parameter benötigen.

Über die folgende Aussage lässt sich nun wiederum streiten, aber ich würde sagen, wann immer es geht, Interfaces benutzen. Klassenhierarchien baut man auf, um Codeduplizierung zu vermeiden. Wenn es sich anbietet, kann man ohne Sorgen natürlich beides machen (also Interfaces und abstrakte Klassen kombinieren), wie es z.B. im Java Collection-Framework zuhauf gemacht wird.

 

[1668mib]

@captmcneil: Ich denke wenn man die Programmiersprache zu Beginn auf Java eingegrenzt hat, dürfte klar sein, dass gesagtes auch nur für Java gilt...

Weil ob es Klassen und Interfaces etc überhaupt gibt, hängt auch schon ab von der Programmiersprache, aber deren Vorhandensein hast du ja auch nicht zur Debatte gestellt... ;-)

"Ein Beispiel hierzu ist das Collection-Framework in Java: es ist guter Stil" <-- ich finde das ist weniger Stil als viel mehr Funktionalität.
Bei einer abstrakten Klasse schränkt man die mögliche Liste enorm ein... bei einem Interface gibt es mehr Freiheiten... wie bereits gesagt sind Interfaces der "Ersatz" für Mehrfachvererbung.

Wenn ich eine Klasse zu einer Liste machen will aber sie von einem anderen Nicht-Listen-Typ ableiten muss, würde ich ohne Interfaces ein Problem haben...

 

[ice-breaker]

Der wichtigste Punkt über Interfaces wurde meiner Meinung nach noch gar nicht erwähnt:
Du kannst mit Interfaces eine Schnittstelle definieren, die du gerne haben möchtest, gibst aber niemandem Restriktionen in der Implementierung.

Oft wird ja von Anfängern für soetwas eine abstrakte Klasse nutzt, das Problem dabei ist aber, dass die Vererbungshhierarchie festgeschrieben ist. Jemand muss von Klasse X ableiten, wenn du jedoch X zu einem Interface machst hat man deutlich mehr Möglichkeiten, man kann das Interface definieren und zugleich noch selbst eine beliebige Vererbungsstrategie nutzen.

Also Schnittstellen immer als Interfaces definieren, das ermöglicht die größte Flexibilität.
In Büchern über Software-Entwicklung bzw. Design Patterns wirst du deshalb auch immer folgendes Leitmotto finden "gegen Schnittstellen programmieren und nicht konkrete Implementierungen".

 

[1668mib]

@ice-breaker:
"Wenn ich eine Klasse zu einer Liste machen will aber sie von einem anderen Nicht-Listen-Typ ableiten muss, würde ich ohne Interfaces ein Problem haben... "
würdest du nicht sagen, dass das dem entspricht, was du etwas ausführlicher erklärt hast? ^^

Edit:
Ja, war kompliziert, die Uhrzeit kam meinem Gehirn nicht entgegen beim Finden von Worten ;-)

 

[ice-breaker]

Jup, aber den Satz hab ich beim drüberlesen nicht so verstanden, zu kompliziert für mich ^^