Nutzungs-/Bekanntheitsbeziehung zw. Beweger und -tem

[milchreis]

Hallo,

wenn ich Bewegung in eine Klasse abstrahieren möchte, sollte diese Klasse denjenigen den sie bewegt kennen (um ihn zu manipulieren)?
Oder doch lieber einfach nur Eingabeparameter annehmen um diese modifiziert zurück zu geben?

//Bleistift:

PHP-Code:

package  
{
    import flash.display.DisplayObject;
    /**
     * nicht weltverbessernd und bewegt trotzdem was
     * @author milchreis
     */
    public class MovementA 
    {
        //v, a, etc.
        
        private var _t:DisplayObject;
        
        public function MovementA(target:DisplayObject) 
        {
            _t = target;
        }
        
        public function update():void
        {
            //_t verschieben
        }
    }

} 


+ einfache Nutzung
- hält Referenz auf Objekt
- kann nur DisplayObjects bewegen

//oder

PHP-Code:

package  
{
    /**
     * Parks' Bus - hier kann jeder mitfahren
     * @author milchreis
     */
    public class MovementB 
    {
        //v, a, etc.
        
        public function MovementB() 
        {
            
        }
        
        public update (x, y, phi):RückgabeKonstrukt
        {
            //aus x,y,phi Rückgabekonstrukt ermitteln.
        }

        //bzw. so hier
        
        public update ():void
        {
            // 
        }
        
        public function get dx ():Number
        {
            return _dx;
        }
        
        //etc.
    }

} 


+ kann auch zB Punkte bewegen
- umständlich


Oder ganz anders?

[_kweso]

meine mama hätte wohl gesagt: das kannst du machen wie die dachdecker...

aber eigentlich find ich das zweite beispiel gar nicht umständlicher.
lg
kws

[ING]

hängt sicherlich auch von der anforderung ab, methode A ist ein ticken performanter und wenn du auch irgendwelche eigenschaften der animierten objekte in der animation berücksichtigen willst bleibt eigentlich auch nur A, weshalb methode A auch zwingend typ gebunden ist.

[milchreis]

War mehr eine theoretische Überlegung, aber Anforderungen ist schon das Stichwort. So eine Bewegung sollte sich relativ einfach gegen eine andere tauschen lassen, also A.

Danke euch.

[joeydee]

Ich mache das nur in die eine Richtung: Nur der Container (Szenenmanager) kennt seine Objekte die er verwaltet. Dem Objekt ist es egal von wem es verwaltet wird. Alle Auswirkungen die ein einzelnes Objekt auf die Szene hat, wird nur vom Szenenmanager entschieden, der kennt ja alle Objekte und deren Eigenschaften, und kann relevante Informationen gezielt an Objekte weitergeben die das interessieren könnte - das reicht.

Außerdem kann ich nur dazu raten, Objektberechnungen und deren Anzeige strikt getrennt zu halten. Kommt auch aus meinen 3D-Erfahrungen: da soll auch mal der Renderer ausgetauscht werden können. Oder Berechnungen ganz ohne Anzeige durchgeführt werden können.

[speedjunkie]

Zitat von milchreis

War mehr eine theoretische Überlegung, aber Anforderungen ist schon das Stichwort. So eine Bewegung sollte sich relativ einfach gegen eine andere tauschen lassen, also A.

Danke euch.

Ist zwar ein Framework Beispiel aber zielt denke ich auch auf Deine theoretische Frage.

Siehe Illustration:view-controllers.png

[milchreis]

Zitat von speedjunkie

Siehe Illustration:view-controllers.png

Variante A wäre dann also ein View Controller. Und was fange ich jetzt mit dieser Erkenntnis an?

Und wie kann ich mit dieser Variante die Anzeige von der Bewegungslogik trennen?
Es wird ja immer ein DisplayObject erwartet. Es ist also nicht möglich zB ein 3D Objekt zu bewegen, oder ein Starling Anzeigeobjekt. =(

Also doch Variante B?

[joeydee]

Nein, mit Variante A hast du noch nichts getrennt, das ist aber schon das richtige Prinzip von Abhängigkeiten. Allerdings sind wir da eigentlich noch auf einer ganz anderen Ebene.
Du hast hier übrigens noch weitere Alternativen:
- Du übergibst eine temporäre Referenz in der update-Methode.
- Es gibt eine Reihe statischer Methoden wie Movements.movementA(myObject), dann brauchst du dafür nichtmal eine neue Instanz.

Typ-unsicher(!!!) kannst du beliebige Objekte, bei denen du x und y vermutest, auf diese Weise verarbeiten:
if(myObject.hasOwnProperty("x"))myObject["x"]=...
Aber das ist nicht ganz Sinn der Objektorientierung und kann eine Menge Fehler produzieren, die der Compiler nicht checken kann und daher erst spät oder nur unter bestimmten Umständen auftauchen, die du vielleicht gar nicht getestet hast.



Wenn du völlig unterschiedliche Objekte ohne gemeinsame Wurzel typsicher bewegen willst (Points und DisplayObjects z.B.), rate ich zuerst dazu, diese über einen gemeinsamen Datentypen zu abstrahieren (kapseln).
Vielleicht interessiert dich dieser Aufbau in Grundzügen:

GenericObject (könnte z.B. als Interface, als Basisklasse einer Vererbungskette oder final und dafür in sich voll generisch angelegt werden - ist KEIN Display-Object und weiß auch nicht, wo, wie und ob es überhaupt dargestellt wird)
- enthält x und y
- kann einen Verweis zu einem DisplayObject zur Darstellung enthalten
- kann ein Movement enthalten, etc.
- hat getter/setter, um z.B. mit Point-Objekten zu arbeiten (oder arbeitet gleich mit Point statt x,y)
- hat eine update-Methode, in der u.a. das Movement aufgerufen wird. Der Positions-Abgleich für das DisplayObject hat hier nichts zu suchen, das ist Sache des entsprechenden Renderers, denn hier wissen wir ja noch gar nicht ob das überhaupt gebraucht wird.

Ein Movement
- kann GenericObjects (deren x- und y-Eigenschaft, nicht deren (optionales) DisplayObject etc.!) verändern. Entweder statische Methode oder festverdrahtet über Variante A oder per temporärer Referenz: update(myGenericObject)

Ein SceneManager
- hat eine add-Methode für GenericObjects und hält damit eine Liste aller Objekte der Szene
- hat eine remove-Methode, die sämtliche notwendigen Referenzauflösungen vornimmt oder anstößt
- hat eine update-Methode, welche u.a. die einzelnen update-Methoden der Objekte in einer Schleife aufruft

Darstellung:
Ein Renderer
- kann ein GenericObject (bzw. einen Vector/Array davon, ggf. auch einen SceneManager) lesen
- kann entscheiden, ob das Objekt in der aktuellen Darstellung überhaupt angezeigt werden muss (Culling)
- kann dann aus dessen Inhalt eine Darstellung generieren und anzeigen
--> z.B. die Position eines DisplayObjects mit der des GenericObjects abgleichen und dieses in einen bestimmten Container adden falls es noch nicht drin ist (Spielfeld-Renderer)
--> oder stattdessen z.B. an der Position eines GenericObjects einen Kreis einer bestimmten Größe und Farbe in ein bestimmtes graphics-Objekt zeichnen und einen Text mit einer bestimmten Information an derselben Position darstellen (Map-/Radar-/HUD-Renderer)


Das generelle Designproblem bei solchen Objekten ist, dass man an Objektunterscheidungen (z.B. hat es intelligenz?) und entweder an eine strenge Vererbungskette (ein Feind ist ein intelligentes Objekt ist ein sich bewegendes Objekt ist ein Objekt -> es gibt kein unbewegtes Objekt das gleichzeitig Feind ist) und/oder an mitgeschleppten und ggf. genullten Ballast gebunden ist.
Mir ist noch ein anderer Ansatz bekannt, wo z.B. das Movement zwar sein Grundobjekt kennt, nicht aber umgekehrt. Damit kann man sozusagen "blind" beliebige Funktionalität anstöpseln, ohne dass das Objekt entsprechend erweitert werden muss. Funktionsinstanzen gleichen Typs werden dann jeweils von eigenen passenden Controllern verwaltet. Was natürlich wieder ganz andere Probleme nach sich zieht... also bleib besser bei dem obigen Beispiel :-)

[milchreis]

Ein Objekt, das ein Movement benutzt und noch aus anderen Komponenten zusammen gebaut ist (zB einer grafischen Komponente), nahm ich sowieso an.

Wenn man nach bestimmten Funktionen verlangt, ist die erste Idee auch "Interface". Aber Point besitzt eben nur öffentliche Eigenschaften x und y.

Ich bräuchte eine Garantie, das im übergebenen Objekt eine Eigenschaft "x" gesetzt werden kann, egal ob über public setter oder var.

Diese Garantie liefert mir zwar das Interface, aber es erscheint mir sinnlos, dieses zu implementieren, da die Basisklasse (hier Point) die Anforderungen prinzipiell auch so schon erfüllt.
Beziehungsweise müsste ich diese Änderungen erst an ein Point Objekt weiterleiten.

Möchte man Movement allein verwenden, muss die zu steuernde Klasse erst umständlich das Interface implementieren, also einen Adapter basteln.

Das ist alles ganz schön umständlich =(

[joeydee]

Wie gesagt, wenn du ein Allesfresser-Modul willst, dann nimm if(myObject.hasOwnProperty("x"))myObject["x"]=...
Die Prüfung passiert dann eben erst zur Laufzeit. Und so werden das wohl auch Tween-Engines machen.

Soll dagegen der Compiler das schon erkennen, MUSST du einen gemeinsamen Nenner schaffen wo keiner existiert, da geht wohl kein Weg dran vorbei.
Wenn du sowieso ein ganzes System drumherum bauen willst, dann mach das gleich richtig, und versuch nicht die eierlegende Wollmilchsau zu entwickeln ;-)

[milchreis]

Zitat von joeydee

Soll dagegen der Compiler das schon erkennen, MUSST du einen gemeinsamen Nenner schaffen

Gemeinsamer Nenner bei A wäre ein Interface, bei B eine Matrix.

Ist's nun Jacke wie Hose was ich nehme?