Zurück   Flashforum > Flash > ActionScript > Softwarearchitektur und Entwurfsmuster

Antwort
 
LinkBack Themen-Optionen Ansicht
Alt 15-12-2008, 09:21   #1 (permalink)
ChronoGuard
 
Benutzerbild von SpecOps-12
 
Registriert seit: Mar 2002
Ort: Saarbrücken
Beiträge: 2.654
Vorteil Interface gegenüber Vererbung?

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.
__________________
we will stop enhancing the truth in 3, 2, ...

Geändert von SpecOps-12 (15-12-2008 um 09:25 Uhr)
SpecOps-12 ist offline   Mit Zitat antworten
Alt 15-12-2008, 09:27   #2 (permalink)
Perverted Hermit
 
Benutzerbild von Omega Psi
 
Registriert seit: Mar 2004
Ort: Bremen
Beiträge: 13.379
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.
Omega Psi ist offline   Mit Zitat antworten
Alt 15-12-2008, 09:38   #3 (permalink)
ChronoGuard
 
Benutzerbild von SpecOps-12
 
Registriert seit: Mar 2002
Ort: Saarbrücken
Beiträge: 2.654
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.
__________________
we will stop enhancing the truth in 3, 2, ...
SpecOps-12 ist offline   Mit Zitat antworten
Alt 15-12-2008, 09:39   #4 (permalink)
Perverted Hermit
 
Benutzerbild von Omega Psi
 
Registriert seit: Mar 2004
Ort: Bremen
Beiträge: 13.379
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 ist offline   Mit Zitat antworten
Alt 15-12-2008, 09:40   #5 (permalink)
Perverted Hermit
 
Benutzerbild von Omega Psi
 
Registriert seit: Mar 2004
Ort: Bremen
Beiträge: 13.379
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.
Omega Psi ist offline   Mit Zitat antworten
Alt 15-12-2008, 10:00   #6 (permalink)
mut
Neuer User
 
Registriert seit: Jul 2008
Beiträge: 213
Zitat:
Zitat von SpecOps-12 Beitrag anzeigen
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.
Code:
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.
Code:
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.
mut ist offline   Mit Zitat antworten
Alt 15-12-2008, 10:03   #7 (permalink)
Perverted Hermit
 
Benutzerbild von Omega Psi
 
Registriert seit: Mar 2004
Ort: Bremen
Beiträge: 13.379
Ich modelliere immer über Interfaces... das ist immer der kleinste gemeinsame Nenner. Und Interfaces erlauben mal definitiv eine bessere Realisierung von Polymorphie.
Omega Psi ist offline   Mit Zitat antworten
Alt 15-12-2008, 11:37   #8 (permalink)
ChronoGuard
 
Benutzerbild von SpecOps-12
 
Registriert seit: Mar 2002
Ort: Saarbrücken
Beiträge: 2.654
@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..
__________________
we will stop enhancing the truth in 3, 2, ...
SpecOps-12 ist offline   Mit Zitat antworten
Alt 15-12-2008, 11:41   #9 (permalink)
Perverted Hermit
 
Benutzerbild von Omega Psi
 
Registriert seit: Mar 2004
Ort: Bremen
Beiträge: 13.379
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.
Omega Psi ist offline   Mit Zitat antworten
Alt 15-12-2008, 12:43   #10 (permalink)
ChronoGuard
 
Benutzerbild von SpecOps-12
 
Registriert seit: Mar 2002
Ort: Saarbrücken
Beiträge: 2.654
Langsam wird es klarer.
__________________
we will stop enhancing the truth in 3, 2, ...
SpecOps-12 ist offline   Mit Zitat antworten
Alt 15-12-2008, 14:18   #11 (permalink)
Perverted Hermit
 
Benutzerbild von Omega Psi
 
Registriert seit: Mar 2004
Ort: Bremen
Beiträge: 13.379
Siehe Interfaces einfach als der kleinste gemeinsame Teiler, der möglich ist.
Omega Psi ist offline   Mit Zitat antworten
Alt 13-02-2009, 09:38   #12 (permalink)
thinkin aBout tha lib.
 
Benutzerbild von kaneda
 
Registriert seit: Nov 2001
Ort: Kölle
Beiträge: 1.379
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.
__________________
Back to community with http://leichtgewicht.at
kaneda ist offline   Mit Zitat antworten
Alt 27-02-2009, 10:54   #13 (permalink)
Perverted Hermit
 
Benutzerbild von Omega Psi
 
Registriert seit: Mar 2004
Ort: Bremen
Beiträge: 13.379
Ein weiterer Vorteil ist die Typsicherheit, wenn man mal Vererbungshierarchien ändern muss.
Omega Psi ist offline   Mit Zitat antworten
Alt 07-03-2009, 13:32   #14 (permalink)
Developer
 
Benutzerbild von malthoff
 
Registriert seit: Sep 2001
Ort: Stuttgart
Beiträge: 519
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.

Geändert von malthoff (07-03-2009 um 13:33 Uhr)
malthoff ist offline   Mit Zitat antworten
Alt 08-03-2009, 17:03   #15 (permalink)
Perverted Hermit
 
Benutzerbild von Omega Psi
 
Registriert seit: Mar 2004
Ort: Bremen
Beiträge: 13.379
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?
Omega Psi ist offline   Mit Zitat antworten
Antwort

Lesezeichen

Themen-Optionen
Ansicht

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks sind an
Pingbacks sind an
Refbacks sind an



Alle Zeitangaben in WEZ +1. Es ist jetzt 20:53 Uhr.

Domains, Webhosting & Vserver von Host Europe
Unterstützt das Flashforum!
Adobe User Group


Copyright ©1999 – 2014 Marc Thiele