Ich würde Jederzeit ein Interface einer abstrakten Klasse vorziehen, solange in der Klasse nur Methoden ohne Implementierung vorgesehen sind. Sobald es aber an Felder und vollständig implementierte Methoden geht, warum nicht die abstrakte Klasse verwenden? Sie hat durchaus ihren Anwendungsfall und diese Linie zu ziehen: wann verwende ich was ist das eigentlich Interessante.

Den Ergebnis hat Thomas bereits sehr schön ausgedruckt:

“Wenn ich (als Entwickler) Klassen eines Moduls eines Anderen verwenden will/muss, schaue ich mir lediglich die Dokumentationen seiner Interfaces an. Wie seine konkreten Klassen, die ich letztendlich benutze, funktionieren, braucht mich nicht zu interessieren.”

Du schreibst:

“Interfaces haben die wunderbare Eigenschaft, dass hier “Mehrfachvererbung” geht, was bei Klassen nicht funktioniert.”

Ich finde, “Mehrfachvererbung” ist hier die so ziemlich unpassendste Formulierung. #7 und #11 treffen’s wohl am Besten:

Erbt man von einer abstrakten Klasse, so hat die erbende Klasse (erstmal) automatisch alle Eigenschaften der abstrakten Klasse. Die Eigenschaften und Fähigkeiten können unter Umständen nicht einmal überschrieben werden.

Ein Interface hingegen gibt tatsächlich lediglich vor, dass eine implementierende Klasse die im Interface definierten Eigenschaften und Fähigkeiten besitzen muss. Hier sehe ich insbesondere bei großen Projekten einen weiteren Nutzen:

Wenn ich (als Entwickler) Klassen eines Moduls eines Anderen verwenden will/muss, schaue ich mir lediglich die Dokumentationen seiner Interfaces an. Wie seine konkreten Klassen, die ich letztendlich benutze, funktionieren, braucht mich nicht zu interessieren.

-> Kann mir jemand ein Beispiel aufzeigen, bei dem man abstrakte Klassen oder Interfaces braucht…

Joe -
hats voll getroffen. So ähnlich siehts bei mir auch meistens aus.
Eine abstrakte Klasse, die 90% der Standardfunktionalität implementiert, und ein passendes Interface dazu, das die
benutzenden Klassen von genau dieser Implementierung löst.

Das gibt dem Entwickler die Möglichkeiten, die Standardmethoden (geerbt von der abstrakten Klasse) anzupassen, oder eine komplett eigenständige Implementierung – eventuell sogar mit einer neuen abstrakten Klasse – drüberzubügeln.

Johannes -
hat genau die Denkweise erkannt, die ich (leider) immer wieder -und gehäuft bei Sprachen die OOP erst im Nachhinein bekamen (PHP/VB/Delpi/Perl…) – antreffe.

Es gab halt irgendwann mal ein Tutorial über Klassen und eine Beispielimplementierung (MySQL oder Mail oder http://FTP...), die genau diese eine Möglichkeit der Vererbung nutzt.
Als Fazit bleibt dem Neuling das Gefühl, jetzt endlich auch mal dass Schlüsselwort “class” benutzt zu haben und somit ein OO-Design zu haben.
Ich nenne das PWO (Programming-With-Objects), anstatt OOP, da die Objekte im Endeffekt nur als erweiterte includes benutzt werden.

mfg
straffi

denic-ergebnis diese posts:
– Die Domain “drueberzubuegeln.de” ist nicht registriert
– Die Domain “programming-with-objects.de” ist nicht registriert.