Algorithmus unabhängig von Koordinate formulieren

[Janoscharlipp]

Moin,
ich schreibe gerade ein äußerst pragmatisches kleines Framework, welches unter anderem auch ein Package bietet, sich um das Layout von DisplayObjects zu kümmern.
Viele Layouts gibt es nun in den zwei Varianten horizontal und vertikal, der Algorithmus ist aber in beiden Fällen der gleiche, es sind nur jeweils x und y, oder with und height vertauscht.

Ein Beispiel wäre beispielsweise ein Layout, das Elemente nebeneinander, oder untereinander anordnet.
Ich bilde das durch die Klassen HStripe und VStripe ab, die beide die Basisklasse Stripe beerben.

Im Moment bietet Stripe eine orientation:Orientation Eigenschaft, in der HStripe eine horizontale Orientation, und VStripe eine vertikale Orientation ablegt. Der Orientation habe ich dann die Möglichkeit gegeben, aus Size und Point-Objekten den jeweiligen Wert auszulesen, bzw. ihn zu schreiben, und auch auf die jeweils gegensätzliche Orientation zuzugreifen.

Ein Teil des Algorithmus sieht dann beispielsweise so aus:

PHP-Code:

orientation.other.setDimension(childSize, orientation.other.getDimension(size));
orientation.setDimension(childSize, orientation.getDimension(childSize) + deltaPerCell); 


Ohne jetzt genauer auf den Code eingehen zu wollen, denke ich ist klar, dass das schlecht lesbar, und auch nicht unbedingt schnell ist.

Die einzige Alternative die mir einfällt ist, die Teile des Algorithmusses, die konkrete Werte benötigen in eigene Funktionen auszulagern, und diese dann in den Vxxx und Hxxx Klassen mit den konkreten Implementierungen zu überschreiben. Besonders elegant finde ich das aber auch nicht.
Hat jemand von euch bessere Vorschläge?

[nky]

Hi,
ich finde das hört sich nach einem Fall für ein Decorator Pattern an.

Ich würde in die abstrakte Klasse eben den Algorithmus reinpacken, und dann 2 Decorator dafür erstellen die dann eben die Werte entsprechend setzen. Das fände ich so spontan den elegantesten Ansatz. Mal gespannt was der Rest dazu meint

Viele Grüße
nky

[Omega Psi]

Ich würde eine Strategy implementieren. Wenn du auf die dynamischen Eigenschaften der Sprache zurückgreifst und beide Implementierungen bis auf die verwendeten Eigenschaften identisch sind, dann brauchst du auch nur eine Implementierung:

package fs.strategies
{
    public interface ILayoutStrategy
    {
        /**
         *
         * @param displayObjects the displayObjects to arrange.
         *
         * @param positionPropertyName The name of the property to position the DisplayObject instances (x or y).
         *
         * @param dimensionPropertyName The name of the property to determine the needed size (width or height).
         * The parameter should correspond to the positionPropertyName parameter.
         *
         */
        function arrange(displayObjects:Array, positionPropertyName:String, dimensionPropertyName:String):void
    }
} 

Nachtrag: ich würde wohl auf die dynamischen Eiegnschaften verzichten, das gibt nur Ärger Also zwei Methoden in eine Strategy (für horizontal und vertical).

[Janoscharlipp]

nky, könntest du das genauer erklären? Ich bin mit den ganzen Patterns nicht so firm. Wie sähe denn dann bei dir der obige Ausschnitt aus dem Algorithmus aus?

Omega Psi, das heißt du würdest den Algorithmus zweimal schreiben?
Das mit dem dynamischen Zugriff schließe ich mal aus

[Omega Psi]

Ja, oder: du übergibst noch ein Argument "direction" und variierst so. Intern arbeitest du mit Variablen die du aus x/width und y/height ziehst und am Ende setzt du dann die konkreten Werte wieder anhand dieses Arguments.

[Janoscharlipp]

Das Problem das ich damit habe ist, dass ich viele Size-Objekte, und viele Point-Objekte habe, und zu jedem bräuchte ich zwei Variablen, um die Werte "orientiert" abzulegen.
Zudem habe ich dann immer einen ziemlichen Aufwand, diese Variablen zu initialisieren, und am Ende wieder auszulesen.

Ich spiele gerade noch mit dem Gedanken, eine "orientierte" Vektor-Klasse einzuführen, die u und v bietet, die dann auf ein Objekt gemappt werden. Ich dazu zwei Subklassen anlegen, die dann durch überschreiben aller Methoden auch ohne If-Abfragen alle Operationen durchführen können. Das wäre vielleicht von der Performance noch erträglich.

[kaneda]

Zweimal implementieren ist vielleicht tatsächlich das schnellste ... (praktisch gesehen ist vermutlich nur alles in eine if anweisung kapseln noch schneller...)

Naja - geht ja hier um OOP: sowohl das decorator als auch das Strategy kann es in deinem fall ja an verschieden verwenden...

Beispiel: Strategy: Im Prinzip kannst du den gesammten Algorithm oder nur häufige teile in eine Strategy auslagern:

   ...
   var distance: Number = 0;
   for (var i: int = 0; i<objects.length; i++ )
   {
      strategy.setOffset( objects[i], distance );
      distance += strategy.getSize( objects[i] );
   }
   ...

class XStrategy
{
   function setOffset( object: DO, distance: Number ): void
   {
       object.x = distance;
   }
   function getSize( object: DO ): Number 
   {
      return object.width;
   }
}

Naja ... momentan fällt mir wohl nichts besseres mehr ein

[Janoscharlipp]

Hi, vielen Dank für deinen Beitrag. Bis auf das deine Strategy auch Strategy heißt, ist sie aber auch nichts anderes, als meine Orientation-Klasse, oder übersehe ich da was?

EDIT: bist du von den Toten auferstanden?

[kaneda]

Also eigentlich wollte ich darauf hinweisen das ne strategy Strategy ja auch unterschiedlich verwendet werden kann (sorry für spätes feedback: bin auf Urlaub):

-> Input-> Decision -> Delegation to Algorithm Strategy -> Output

var strategy: IStrategy = DEFAULT_STRATEGY;
if( ... )
{
  strategy = OTHER_STRATEGY;
}
return strategy.deal( parameter );

ist die einfache verwendungsweise ... Dabei wird die Strategy mit einer Methode ausgestattet die sich um eine Aufgabe kümmert. Pro Methode quasi eine Methode in der Strategie.

In meinem Beispiel wollt ich zeigen das man auch das machen kann:

-> Input -> Decision -> Execution of Algorithm ( -> Detail implementation strategy ) -> Output

var strategy: IStrategy = DEFAULT_STRATEGY;
if( ... )
{
  strategy = OTHER_STRATEGY;
}

var a: Number = 1.0;
var b: int = strategy.evaluate("b");

return strategy.process( a, b+2 );

Hätte dann halt zur Folge das die Strategy nicht so frei ist, dafür gibts weniger doppelt ( weniger fehler?! ).

PS.: Oh! Also ist doch noch jemand da der sich an mich errinnert . Ich bin ja nicht gestorben, so zwischendurchmal, hatte nach Macromedias ActionScript3 Ankündigung die ganze Sache eine Zeit lang satt ... (Hab zuviel Schweiss & Herzblut in As2 gesteckt um es dann einfach abgesägt zu sehen). Ich glaub ich bin langsam drüber weg und traue mich wieder zurück.