Kompositum pro & contra

[_malte]

Hi - Wer von euch benutzt gerne mal ein Kompositum um den (gesamten) Inhalt einer Flash-Site zu modellieren? Was sind eure Erfahrungen damit? Danke & Grüße!

[Omega Psi]

?

Du weisst schon, dass das keinen Sinn macht?

Ein Composite ist nicht nur ein Composite, weil es strukturell dem Pattern gleicht.

[malthoff]

Meine Erfahrung damit ist, dass ich das Composite Pattern ab und zu nutze, inklusive Zugriff per Iterator, das aber in vielen Fällen für lästig halte.

Wie so häufig bei der Nutzung von Pattern - sie spielen ihre Stärken erst
aus, wenn die Anwendung groß wird oder Du mit mehreren Leuten ein
System hochziehst. (nein, Composite macht auch im kleinen Sinn, aber das
Verstecken der Datenstruktur durch Iterator nicht so)

Du nutzt Composite ja indirekt schon durch die DisplayList, wo DisplayObjectContainer(DOC) andere DOC enthalten...in unendlicher Tiefe...
Stimmt das eigentlich? Kann man 1.000.000 Sprites in ein Sprite packen?

[Omega Psi]

Zitat von Dr.Ache

Wie so häufig bei der Nutzung von Pattern - sie spielen ihre Stärken erst
aus, wenn die Anwendung groß wird oder Du mit mehreren Leuten ein
System hochziehst. (nein, Composite macht auch im kleinen Sinn, aber das
Verstecken der Datenstruktur durch Iterator nicht so)

Das Composite pattern macht dann Sinn, wenn es eine adäquate Lösung zu einem Problem ist. Unabhängig von der Anzahl der Entwickler/Größe des Projektes und zudem ist die Kapselung von Daten immer zu implementieren - vor allen Dingen wenn man schon in Patterns denkt.

Zitat von Dr.Ache

Du nutzt Composite ja indirekt schon durch die DisplayList, wo DisplayObjectContainer(DOC) andere DOC enthalten...in unendlicher Tiefe...
Stimmt das eigentlich? Kann man 1.000.000 Sprites in ein Sprite packen

Wenn die Runtime 1000000 Objekte verwalten kann...

[sebastian]

Zitat von Omega Psi

Das Composite pattern macht dann Sinn, wenn es eine adäquate Lösung zu einem Problem ist. Unabhängig von der Anzahl der Entwickler/Größe des Projektes und zudem ist die Kapselung von Daten immer zu implementieren - vor allen Dingen wenn man schon in Patterns denkt.

Eben. Das ist die richtige Herangehensweise. Also nicht fragen, wie kann ich
Pattern XY anwenden, sondern fragen, wie kann ich Problem XY lösen.

gruß

[_malte]

Omega Psi, meinst Du es macht keinen Sinn, weil die abzubildenden Inhalte evtl. zu uneinheitlich sind?

Mein Ansatz geht in die Richtung, dass ich meine Composite-Klasse um spezialisierte Typen erweitern will. Beispiel Projektportfolio:
- Composite enthält u.a. die Methode addChild
- ProjektKategorie erweitert Composite
- Projekt erweitert Composite
...
projektKategorieInstanz.addChild(projektInstanz)

Damit ich eine traversierbare Baumstruktur bekomme, die sich z.B. leicht in einer dyn. Navigation darstellen lässt.
( Ich bin davon ausgegangen, dass das im Prinzip nichts anderes ist, als z.B. DisplayObjectContainer für eigene UIs zu erweitern. )

Ist schon klar, dass es für sowas eigentlich XML gibt
Möchte ich aber in diesem Fall vermeiden, weil ich unterschiedliche Datenquellen berücksichtigen muss. Ausserdem hätte ich gerne voneinander unterscheidbare Typen anstatt XML-Nodes.

Habe ich Composite vielleicht insofern falsch verstanden, als dass alle beteiligten Objekte vom SELBEN Typ sein müssen? Und eben keine Instanzen von Subklassen? Dann wäre die Displaylist aber eigentlich auch kein richtiges Composite...?

Noch mal vielen Dank für euer Feedback.

[Omega Psi]

Ganz schön viel auf einmal, also...

Zitat von _malte

Omega Psi, meinst Du es macht keinen Sinn, weil die abzubildenden Inhalte evtl. zu uneinheitlich sind?

Nein, denn dafür gibt es Composites. Mein Punkt ist: du adressierst kein konkretes Problem. Du willst eine Lösung für deinen ganzen Code haben und das geht nicht - es sei denn du arbeitest mit der DisplayList... das ist aber auch keine Lösung.

Zitat von _malte

Mein Ansatz geht in die Richtung, dass ich meine Composite-Klasse um spezialisierte Typen erweitern will. Beispiel Projektportfolio:
- Composite enthält u.a. die Methode addChild
- ProjektKategorie erweitert Composite
- Projekt erweitert Composite
...
projektKategorieInstanz.addChild(projektInstanz)

Das ist keine bewert- oder kommentierbare Ausgangssituation.

Zitat von _malte

Damit ich eine traversierbare Baumstruktur bekomme, die sich z.B. leicht in einer dyn. Navigation darstellen lässt.
( Ich bin davon ausgegangen, dass das im Prinzip nichts anderes ist, als z.B. DisplayObjectContainer für eigene UIs zu erweitern. )

Nein. Denn im Fall von DisplayObjects und -Containern handelt es sich um die Implementierungen. Dich interessieren aber in erster Linie die aufzubauenden (Daten-, Komponenten-)Strukturen. Und diese Strukturen adressieren immer ein Problem (beispielsweise eine hierarchische Navigation).

Hier mal ein paar Links:
Wie organisiert man den Zugriff auf Inhalte?
Navigation
Problem mit eventlistener <- der ist wichtig, UML unten.

Zitat von _malte

Ist schon klar, dass es für sowas eigentlich XML gibt
Möchte ich aber in diesem Fall vermeiden, weil ich unterschiedliche Datenquellen berücksichtigen muss. Ausserdem hätte ich gerne voneinander unterscheidbare Typen anstatt XML-Nodes.

Nein, XML willst du nur verwenden, um Daten persitent zu halten oder um es als Datenaustauschformat zu verwenden. Im Model greifst du nicht direkt auf XML zu.

Zitat von _malte

Habe ich Composite vielleicht insofern falsch verstanden, als dass alle beteiligten Objekte vom SELBEN Typ sein müssen? Und eben keine Instanzen von Subklassen? Dann wäre die Displaylist aber eigentlich auch kein richtiges Composite...?

Nein, sind sie ja eh, da alles DisplayObjectContainer sein müssen. es geht darum, dass sie alle das gleiche Problem adressieren.

Ich würde folgendes machen an deiner Stelle: denke nicht in Pattern sondern versuche die einzelnen Aufgaben durch Komponenten zu lösen. Diese finden dann Lösungen durch und in Patterns (vergleiche: Problem mit eventlistener).

[_malte]

OK, klasse, das sind wirklich gute Anregungen. Dann werde ich mir erst mal über die richtige Fragestellung Gedanken machen, bevor ich mich an die Lösung mache...

Eine Sache noch:

Nein, XML willst du nur verwenden, um Daten persitent zu halten oder um es als Datenaustauschformat zu verwenden. Im Model greifst du nicht direkt auf XML zu.

Soll "nicht direkt" heissen: Zugriff nur über einen Wrapper? Oder sollte man im Model ganz auf XML verzichten? Wo's doch in AS3 eigentlich sehr komfortabel zu handhaben ist.

[Omega Psi]

Ich arbeite gänzlich ohne XML zur Laufzeit in 99% meiner Anwendungen. Auch wenn der Zugriff easy ist: da du nicht typesafe arbeitest, bzw. arbeiten kannst sollte man drauf verzichten.

[Omega Psi]

Wenn du dich mit Architekturen und Patterns befassen möchtest, ich gebe zu diesem Thema einen Workshop bei der kommenden FFK (Link in meiner Signatur).

[malthoff]

oder du beginnst einfach hier zu lesen: sehr wertvolle und gut geschriebene Artikel über Pattern speziell in AS3: www.as3dp.com