Vorteil Interface gegenüber Vererbung?

[SpecOps-12]

Hab mich die letzten Tage mit dem Strategy-Pattern beschäftigt.
Ist auch klar, und ich hab es unbewusst schon öfters eingesetzt, allerdings mit Vererbung. Und ich versteh auch nicht, warum Implementierung der Vererbung überlegen sein soll. Das wird zwar im Headfirst-Buch behauptet, aber nicht einleuchtend begründet.

-Bei der Vererbung kann man die Methoden mit einem Standard belegen, und, wenn eine Abweichung gewünscht ist, mit override überschreiben.

-Bei einem Interface muss jede implementierende Klasse alle Methoden neu anlegen, wobei es bei einigen zu Redundanz kommen kann, was ja eigentlich vermieden werden sollte.

Mir erschließt sich der Vorteil nicht ganz. Exakt das selbe, was ich mit dem Interface erreiche, könnte ich auch über Vererbung erzielen.

[Omega Psi]

Nein, ist es nicht. Denn du arbeitest immer mit Implementierungen und bist dadurch immer typgebunden. Interfaces erlauben es dir vollkommen ohne Implementierungen zu arbeiten.

Nehmen wir mal einen LayoutManager zum Beispiel. Du hast ein Interface ILayout und die Methode apply(DisplayObjectCntainer):void;

Wenn du nun 2 Klassen: VerticalLayout und HorizontalLayout hast... wo soll da die Basisklasse herkommen? Die beiden Klassen sind vom selben Typ, aber die Implementierungen gänzlich unterschiedlich.

[SpecOps-12]

Ich würde dann iLayout etwa so benutzen:

PHP-Code:

var meinLayout:ILayout;
meinLayout = new VerticalLayout();
meinLayout.apply(DisplayObjectContainer); 


Wenn ILayout kein Interface sondern die Basisklasse der beiden andren Layouts wäre, würde es im Umgang mit der meinLayout-Instanz doch keinen Unterschied machen.

[Omega Psi]

Beispiel 2: Du musst outsourcen... um den Entwicklern letzten Endes eine Recht genaue Definition dessen zu liefern, was sie machen sollen, gibt's du am besten Interfaces mit raus. Dadurch ist gleich festgelegt, an welche Verträge sich die Implementierungen halten müssen.

[Omega Psi]

Das ist ja der Punkt. Es geht nicht um den Umgang, sondern um die Modellierung von Software.

Nur Weil du durch Vererbung Code sparen kannst, heisst es nicht, das es dies der Beste Weg ist.

[mut]

Zitat von SpecOps-12

Mir erschließt sich der Vorteil nicht ganz. Exakt das selbe, was ich mit dem Interface erreiche, könnte ich auch über Vererbung erzielen.

Du kannst aber auch nur von einer Klasse erben und müsstest dir dann ggf. eine "krumme" Vererbungshierachie zusammenbasteln

Stell dir doch mal vor du bist in einem Einrichtungshaus und willst zu deiner neuen Küche einen Mülleimer in der gleichen Farbe haben.
Über ein Interface Farbe könntest du allen "Gegenständen" im Möbelhaus die Methode getFarbe() vorschreiben.
So kannst du dann die Farben der "Gegenstände" vergleichen.

kueche.getFarbe() == muelleimer.getFarbe()

Sonst haben diese Gegenstände aber nichts gemeinsam, so dass du eigentlich auch keine sinnvolle Elternklasse erstellen könntest, die die Methode implementiert.

Da du nun sicher sein kannst, das alle "Gegenstände" mit dem Interface Farbe einen Farbwert haben braucht du als Argumenttyp für Parameter dann nur noch Farbe angegeben.
Willst du nun schauen ob eine Tapete, die Komplementärfarbe zu einer Küche im Möbelhaus hat, könnte das so aussehen.

var tapete:Tapete = new Tapete("Gelb");
var kueche:Kueche = new Kueche("Blau");
if(kueche.hatKomplementaerfarbeZu(tapete))
{
trace("Kaufen");
}

Vielleicht willst du auch dass die neue Küche farblich zu deinem Auto passt, usw.

Manchmal fällt es dennoch schwer eine Entscheidung zwischen Vererbung und Interfaces zu fällen, aber was besser ist, hängt dann von Fall zu Fall ab.

[Omega Psi]

Ich modelliere immer über Interfaces... das ist immer der kleinste gemeinsame Nenner. Und Interfaces erlauben mal definitiv eine bessere Realisierung von Polymorphie.

[SpecOps-12]

@mut

Das leuchtet mir auch ein, bis ich an die Umsetzung denke.
Beim Beispiel "Farbe".

Wie könnte ich Polymorphie dort denn nutzen?
Doch auch nur, in dem es Beispielsweise eine Superklasse "Gegenstände" gäbe, die das Interface "Farbe" implementiert, von der im Endeffekt alle anderen Gegenstände erben.

Denn sonst könnte ich nich einfach einen Gegenstand von einem beliebigen Typ erzeugen, der auf jeden Fall über die getFarbe()-Methode verfügt.

In meinem Hirn beißt sich dann an der Stelle die Katze selbst in den Schwanz..

[Omega Psi]

Nein, jede eigenständige Klasse (Tisch, Kanne, Auto...), die auch das Interface Farbe definieren, lassen Polymorphie zu: einmal sind sie Instanzen der jeweiliegn Klasse und einmal Typ des Interfaces Farbe.

[SpecOps-12]

Langsam wird es klarer.

[Omega Psi]

Siehe Interfaces einfach als der kleinste gemeinsame Teiler, der möglich ist.

[kaneda]

Ich hab mir bei Interfaces folgende Regel gemacht: Wenn ich mein kleinster Gemeinsamer Nenner 1 ist ( sprich wenn ich weiß: diese Klasse verwende nur ich, keiner möchte sie ersetzen oder austauschen ) dann kein Interface. Sobald ich einen Ort Konfigurierbar machen möchte (Stichwort Strategy) setze ich ein Interface drauf. Weil ich dann selbst früher oder später eins brauche.

Btw.: Beim verwenden von Klassen spricht man von Typeinterface. Sprich: Auch wenn du eine Klasse schreibst erschaffst du eine Schnittstelle. In anderen Programmiersprachen kann man auch Klassen als Interfacedefinition verwenden. Ein Interface ist prinzipiell ganz gut seperat, auf die art und weise wird besser dokumentiert was Schnittstelle ist und was implementation.

Zudem als Empfehlung: Interfaces sollten so wenig Methoden wie nötig zur Verwendung haben. Dann ist nämlich klar: Das ist das Minimum wo's braucht damit die Klasse geht.

[Omega Psi]

Ein weiterer Vorteil ist die Typsicherheit, wenn man mal Vererbungshierarchien ändern muss.

[malthoff]

Auch wenn die Antwort schon kam hier noch meine Meinung.
Ich sehe den wichtigsten Vorteil wirklich darin, Objekte aus völlig anderen Bereichen (andere Verantwortlichkeiten) unter einem Typ, vom Interface vorgegeben, zusammenzufassen.

Beispiel Serialisierung, also das persistente Speichern von Objekten unterschiedlichster Art als Datensatz. Das Interface ISerialisable implementieren alle Klassen von Objekten, die beim Verlassen der Applikation gespeichert werden wollen. Das können ValueObjects, also reine Datensätze (Einkaufskorb) sein - das können aber auch Objekte aus der DisplayList sein, deren Position beim erneuten Start der Anwendung die alten Werte übernehmen sollen.

Diese Objekte durch eine Vererbungshierarchie zu dieser Funktionalität zu bringen, wäre sicherlich nicht anzuraten.

[Omega Psi]

Das verstehe ich nicht? Je nach Methode der Serialisierung kommst du um eine Reimplementierung nicht herum. Ausserdem heisst das auch, dass Superklassen nicht serialisierbar sind, oder sehe ich das falsch?