noch eine Variante, dann aber neben 3 Konstruktor-Parameter auch 3 Attribute zu modellieren, ein weiterer Schritt,
es könnte bei den Enum-Konstruktor-int-Parametern bleiben und im Enum-Konstruktor dann wie gesagt den Vector3f erzeugen und wie bisher ablegen
Noch besser wäre es keine getVector() Methode im enum zu haben, sondern eine Methode, die dann die tatsächliche Rechnung durch führt, denn Getter sind immer erstmal böse…
Vektoren kann man addieren, subtrahieren und multiplizieren wenn ich alles richtig in Erinnerungen habe. Wenn du dich Richtung X Achse bewegen willst, nimmst du deinen Geschwindigkeitsvektor und addierst ihn mit deinem Positiven X Vektor (hoffe das ist so richtig). Raus bekommst du deinen Bewegungsvektor.
Du schreibst eine Methode die dein Enum annimmt und mit den angegeben Vektor verrechnet.
nope, man multipliziert die beiden… aber ich verstehe was du meinst.
nur soll das enum damit nicht unbedingt etwas zu tun haben. das wäre irgendwie
spaghetti code. danke euch, ich lass das jetzt. so. mir ging es eben nur um diese eine zeile 17,
das ich eben eine kopie returne… wie in c, wenn man keinen pointer verwendet ^^
wenn du so genau darauf achtest, dann ist immer die Alternative, die Klasse Vector3f unveränderlich zu machen,
einen String und BigDecimal kann man in Java gefahrlos herausgeben
bisschen sehr aufwendig gerade an so einer zentralen Stelle wie Enum, ständig Kopien zu erzeugen
Wenn du umbedingt eine Kopie haben willst mach doch in deinem Enum eine statische Vector CopyOf(Direction dir) Methode. So kannst du es dir später aussuchen.
[QUOTE=SlaterB]wenn du so genau darauf achtest, dann ist immer die Alternative, die Klasse Vector3f unveränderlich zu machen,
einen String und BigDecimal kann man in Java gefahrlos herausgeben
bisschen sehr aufwendig gerade an so einer zentralen Stelle wie Enum, ständig Kopien zu erzeugen[/QUOTE]
Vector3f ist von lwjgl… da kann und will ich nichts dran ändern, weil ich dann die ganze vector lib selbst schreiben könnte.
außerdem, selbst wenn ich dort unveränderliche dinge wie in dem fall floats zurückgeben würde, müsste ich, um sie weiterzuverwenden
sie wieder zu nem Vector3f machen - also würde sich an der performance nichts ändern.
[quote=mymaksimus]aber ich verstehe was du meinst.
nur soll das enum damit nicht unbedingt etwas zu tun haben. das wäre irgendwie
spaghetti code.[/quote]Schaun wir mal:public void move(Direction direction, int steps){ while(0<steps--) this.position= direction.moveFrom(this.position); }Ja, wirklich, mehr Spaghetti geht kaum…
nein, das meine ich nicht. ich finde bloß das die richtung an sich nichts mit der bewegung zu tun haben muss.
Der bewegungscode gehört da meiner meinung nach einfach nicht hin.
[quote=mymaksimus]ich finde bloß das die richtung an sich nichts mit der bewegung zu tun haben muss.[/quote]Bewegung hat immer eine Richtung. Selbst die Rotation.
Aber lass Dich von solchen physikalischen Gegebenheiten nicht ablenken… ;o)
[quote=mymaksimus]aber eine Richtung impliziert nicht immer eine Bewegung.
Verstehst du nicht was ich meine?[/quote]Nö.
Eine Richtung bezieht sich auf 2 Punkte in einem Koordinatensystem. Für Deine Berechnung ist es absolut unerheblich, ob Du etwas in diese Richtung bewegst oder es nur dort hin schaut.
Das was Dir als “losgelöst von der Bewegung” erscheint ist der reine Besitz eines Richtungswertes.