Decorator Pattern

[derRaab]

Hallo Leute,

wenn ich für die Flash Komponente einen Decorator entwickeln will, dann muß ich das komplette Interface des Windows implementieren? Das würde bedeuten alle Methoden und Eigenschaften? Also auch die der Superklassen incl. MovieClip?

Ist es also keine gute Idee einen Decorator zu entwickeln um das Window um Funktionen zu erweitern (Resizeable etc.)?

Ich habe meine Funktionalitäten eigentlich schon fertig, wollte die nur auf die Pattern-Architektur übertragen. Aber wenn das so umfangreich ist, macht das dann überhaupt Sinn?

M

[hazy fantazy]

Ja, das dekorierte Window sollte auch wieder ein Window sein, muss also alle Methoden implementieren.

Allerdings, da die mx Klassen ja keine Interfaces implementieren, ist es fraglich, ob das Decoratorpattern überhaupt Sinn macht, bzw. ob man das dann noch so nennen kann.

Wie wäre es denn mit einem MixIn, wie der EventDispatcher?

[elias]

Ich würde auch sagen MixIn oder __resolve().

[Janoscharlipp]

Warum nicht einfach extenden?
Mit der symbolOwner-Variable kannst du dann sogar das Window-Bibliothekssymbol weiterverwenden, solange du deine Fenster mit createClassObject erstellst.
Ansonsten ziest du dir einfach aus der ComponentFLA.fla das Window-Symbol, verknüpfst es mit deiner neuen Klasse, und kompilierst es zu einem besseren Window.

[derRaab]

Hallo. MixIn hab ich noch nicht gehört...mich aber gerade grob eingelesen...und jetzt grad auch verstanden. So wie man den EventDispatcher einbindet nennt man das MixIn. Gut zu wissen.

Aber: Da muß man dann ja auch alle Methoden der Window-Klasse nochmal einschreiben. Kommt also nicht in Frage, weil die Window-Klasse ja unglaublich viele Methoden hat (erbt ja bis runter zum MovieClip einiges).

Krass ist, dass ich __resolve (Object.__resolve property) noch nie verwendet oder gar wahr genommen habe. Wahnsinn. Da denkt man man ist schon ein wenig dabei...

Nun könnte ich mit __resolve zwar so eine Art Decorator bauen, aber per Definition ist das dann ja gar kein richtiger Decorator weil ich ja nicht das komplette Interface implementiere sondern einfach alle Aufrufe bis zum eigentlichen Window durchschleife. Das bedeutet auch, dass ich in Eclipse jeden Window-Methoden-Aufruf im Decorator als Fehler angezeigt bekomme.

Vielleicht implementiere ich im Decorator dann nur den Teil des Interface, den ich wirklich anspreche (z. B. setSize, x, y usw) um die Fehlermeldungen in Eclipse zu unterdrücken. Was denkt Ihr?

[Janoscharlipp]

Was spricht denn gegen das Erben vom Window?
Egal wie du es anders machst, entweder es macht mehr Arbeit, oder es ist unsauber.

[derRaab]

Ich finde halt einfach die Idee hinter dem Decorator Patter cool, aber für sowas ist mir das zu viel getippe. Leider stehen ja die verschiedenen vererbten Interfaces nicht als separat definiertes Interface zur Verfügung. Sonst würd ich mir vielleicht sogar noch die Mühe machen...

Erben vom Window wäre wirklich noch eine Möglichkeit. Aber dann hat halt jedes der Fenster eine Vielzahl von erweiterten Funktionen. Mal sehen. Ich denke nochmal drüber nach. Aber den Weg über die Component.fla kommt nicht in Frage. Ich will die Klasse möglichst ohne weiteren Aufwand verwenden können.

Danke für die Infos!

[hazy fantazy]

Was du vielleicht machen kannst, ist einmal Vererben, und ab da dann Interfaces benutzen. Dann sind es halt keine mx Windows mehr sondern derraab Windows.

de.derraab.container.Window extends mx.container.Window implements de.derraab.container.IWindow

de.derraab.container.ResizableWindow implements de.derraab.container.IWindow, de.derraab.container.IResizable

de.derraab.container.ResizableDragableWindow implements de.derraab.container.IWindow, de.derraab.core.IResizable, de.derraab.core.IDragable

usw.

[Janoscharlipp]

Dann muss er dummerweise auch wieder alle Interface-Funktionen in die Klasse hacken, da ja geerbte Methoden Interfaces nicht erfüllen.

[Omega Psi]

Wieso werden denn, wenn meine Klasse fs.container.Window von mx.container.Window erbt, die Funktionen von xm.container.Windows mit lehren Funktionsrümpfen überschrieben?

Wo erbt denn meine Klasse da irgendwas? Edit: das findet zeugte von schlechtem Deutsch

[Janoscharlipp]

Wie meinen?

[hazy fantazy]

Zitat von Janoscharlipp

Dann muss er dummerweise auch wieder alle Interface-Funktionen in die Klasse hacken, da ja geerbte Methoden Interfaces nicht erfüllen.

Also ich könnte wetten dass das doch geht, hab jetzt nur keine Zeit zum Ausprobieren.

[Omega Psi]

Zitat von Janoscharlipp

Wie meinen?

Ach, ich glaube, ich habe was echt fasch verstanden... Sorry... weitermachen

[derRaab]

@ Janoscharlipp: Ich steh grad auf dem Schlauch. Ich wollte jetzt noch mal einen neuen Versuch machen und eben die bestehende Window-Klasse erweitern. Aber ich finde keinen Window-MovieClip in der ComponentFLA. Hab ich was falsch verstanden?

Und wie funktioniert das mit der symbolOwner Variable?

[Janoscharlipp]

1) C:\Programme\Macromedia\Flash 8\en\Configuration\ComponentFLA\StandardComponents .fla o.ä. öffnen
2) Window-Symbol (das allerletzte im Ordner) kopieren in neue Datei einfügen
3) In neuer Date, Window mit neuer Klasse verknüpfen
4) Symbol in Kompilierten Clip umwandeln, oder als swc exportieren

Hab ein Beispiel unter http://janosch.scharlipp.de/ff/CoolWindow.zip hochgeladen.