spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich brauche oft die Höhe und Breit meiner GUI-Elementen um dynamisch positionieren zu können ohne über den Rand zu zeichnen.

... myWindow.getWidth() ...

EDIT: Achso... Setter für einen Button dessen Größe oder Position sich verändert. In der setWidth() Methode könnte ich dann dafür sorgen, dass diese Button z.B. neu gezeichnet wird.

Ich seh nicht, wieso man für MVC unbedingt Properties brauchen würde. Das Model enthält die Daten und die Logik, wird vom Controller bedient (Methoden) und benachrichtigt das View über Änderungen (Callbacks)...

ich habe mir eben die Zeit genommen, zumindest die erste verlinkte Seite komplett zu lesen
erstmal möchte ich mich nicht zu sehr dazu äußern, allerdings wird auf den letzten Seiten das beschrieben, was dot hier aufzeigt:
warum sollte man Getter (oder Setter) verwenden, wenn es einen Lösungsweg gibt, der suber(er) ist und keine Getter benötigt?
warum sollten beispielsweise von einem Objekt Informationen zum Zeichnen dieses nach außen gezeigt werden, wenn sie doch auch an der gleichen Stelle liegen könnten


ein konkreteres Beispiel:
eine Einheit in einem Spiel und ihr Zeichnen auf dem Bildschirm
mir dürfte jeder zustimmen, dass das Zeichnen innerhalb der Einheit nicht sehr auber ist
also müsste das Zeichnen außerhalb dieser liegen
relevant dafür ist, wo sich die Einheit in der Umgebung befindet
man könnte meinen, die Einheit muss dafür nun Getter implementieren, damit auf diese Eigenschaften zugegriffen werden kann
allerdings ist es nicht notwendig, dass die Einheit weiß, wo sie sich befindet, da dies eigentlich eine Eigenschaft der Beziehung mit der Umgebung ist

die Einheit soll sich bewegen
also könnte man meinen, dass die Einheit dafür auf ihre Position in der Umgebung zugreifen muss
allerdings ist auch das nicht notwendig und ggf. auch sehr unsinnig
es gibt in der Umgebung noch andere Einheiten
wenn eine Einheit ihre Bewegung selbst durchführen will, dann muss sie auch alle anderen Einheiten kennen
dafür müsste die Umgebung wieder Getter für die anderen Einheiten anbieten
es müsste auf Besonderheiten der Umgebung, wie Steigungen (langsamer laufen, andere Animation) geachtet werden
etc.
daher wäre es sinnvoller, die Umgebung das Bewegen der Einheit vornehmen zu lassen, da dadurch kein externer Zugriff auf diese Eigenschaften notwendig ist (die Position der Einheit, die anderen Einheiten der Umgebung, Besonderheiten der Umgebung, ...)


eine bitte an die anderen: lest die verlinkten Seiten ausführlich

Scaldur und wie vereinst dun Bewegung und rendern ohne getter? Eine von zwei Parteien muss die Position speichern und diese an die 2. Übermitteln. Und nein gerade beim MVC Pattern ist es wichtig das ein Model auch eine gewisse Kontrolle und verarbeitung in ihren Gettern und settern hat. Und callbacks helfen dir dabei auch nicht.

Interessantes Beispiel

Aber wie wird die Position einer Einheit (also das Objekt) verändert und woher weiß die Umgebung wo die Einheit steht?

Zitat von »fkrauthan«

Scaldur und wie vereinst dun Bewegung und rendern ohne getter?

was genau meinst du mit dem Vereinen der beiden Dinge?

Zitat von »fkrauthan«

Und nein gerade beim MVC Pattern ist es wichtig das ein Model auch eine gewisse Kontrolle und verarbeitung in ihren Gettern und settern hat.

dem wiederspreche ich nicht, allerdings sage ich (und dot), dass ein Model nur das wissen muss, was ein Model wissen muss

Zitat von »Kevni«

Aber wie wird die Position einer Einheit (also das Objekt) verändert[...]

das wird von der Umgebung übernommen und muss die Einheit selbst eigentlich nicht interessieren
so kann dieser egal sein, ob beispielsweise die Ausrichtung mittels Vektor oder Polarkoordinate gespeichert wird (und wie somit die Ausrichtung aktualisiert werden muss)

Zitat von »Kevni«

[...] und woher weiß die Umgebung wo die Einheit steht?

weil sie es weiß(/speichert)? oO
wie sie das speichert ist der Einheit doch vollkommen egal


auch wenn ich diesen Punkt noch nicht explizit angesprochen habe:
die Einheit benötigt in dem Fall nur einen Verweis auf ein Objekt, welches die benötigte Funktionalität deklariert
ich meine, dass das auf der ersten verlinkten Seite mehr oder weniger angedeutet wurde


da auch grafische Komponenten angesprochen wurden das ganze übertragen auf diese:
eine grafische Komponente muss nicht selbst "wissen" (speichern), wie hoch und breit sie ist und an welcher Stelle sie sich befindet
viele Toolkits für grafische Oberflächen bieten Konstrukte zum Verwalten der Komponenten, wie in Java die verschiedenen LayoutManager
die Komponente selbst darf maximal wissen, wie groß sie gerne wäre, wie groß sie mindestens sein will oder wie groß sie maximal sein will
es könnte beispielsweise eine Komponente geben (ein Fenster o. ä.), welches nur diese eine Komponente enthält und diese sich über die gesamte Größe erstrecken soll
die gewünschte Größe könnte als Ausgangsgröße verwendet werden, sofern dadurch die übergeordnete Komponente selbst nicht zu groß wird und Minimal- und Maximalgröße für die ermittlung der Minimal- und Maximalgrößen der übergeordneten Komponente dienen

man könnte dies noch ein wenig erweitern: 2 Komponenten (z. B. nebeneinander), die sich den Platz teilen
hier ergibt sich die Ausgangsgröße aus den beiden Wunschgrößen und bei der Aufteilung des zur Verfügung stehenden Platzes könnten folgende Möglichkeiten angewendet werden:
beide haben ihre Mindestgröße und des restliche Platz wird erst der einen Komponente zugeteilt, bis die Maximalgröße erreicht ist und dann der anderen
beide sind gleich groß, solange keine der beiden die Maximalgröße erreicht hat, dann wird er restliche Platz der anderen zur Verfügung gestellt
die Größe wird entsprechend der Differenz der Maximalgrößen vorgenommen

nun könnte der (vermutlich) berechtigte Einwand kommen, dass das auch geht, wenn die Komponente ihre tatsächliche Größe kennt (also selbst speichert) und vom Layout-Manager die tatsächliche Größe zugewiesen bekommt
das ist durchaus möglich, ermöglicht aber auch das Ändern der richtig berechneten Werte von außen, was eigentlich nicht gewollt ist
und das, obwohl die jeweiligen Setter eigentlich nur dafür benötigt werden
als Hinweis: die Komponente kann auch weiterhin Getter für die Breite, Höhe und ggf. auch Position haben (was allerdings auch nicht zwingend notwendig ist), allerdings sollte sie sich nur die errechneten Werte abholen


(und aufgrund der Fragen behaupte ich einfach mal, dass noch nicht mal die erste verlinkte Seite _ausreichend_ gelesen wurde)

Ja aber damit ein Controller mit Models arbeiten muss müssen die Werte ausgetauscht werden können ergo Getter und Setter. Um Infos über andere inheiten zu bekommen muss es Getter und Setter dafür geben (Alleine schon wenn die KI reagieren soll). Um Positionen für Bewegen zu haben speicher ich sie im beweungsManager nach deinem system. Nur müssen die Positionen von diesem bewegungsmanager ja in den rendermanager welcher die sachen anzeigt. Dafür braucht der bewegungsmanager wiederum getter. Womit wir trotz dem super tollen design vorschlag von dir nich um Getter und Setter rumkommen die du ja eigentlich vermeiden wolltest.

Ich gebe dot im Grundgedanken absolut Recht. Problem ist aber, dass man oft gar nicht rundrum kommt, weil gewisse Eigenschaften von gewissen Objekten eben von außen beeinflussbar sein müssen. Wie ändere ich sonst die Elemente meiner Menü-Klassen, den Text in meinen GUI-Elemente, die maximalen Lebenspunkte einer Spielfigur, die Haarfarbe einer Spielfigur, die Position eines Objekts in der Welt, etc pp? Das geht eigentlich gar nicht anders als sie als öffentlich ansprechbare Attribute zu deklarieren. Ob die Methode dabei "changeHairColor" oder "setHairColor" heißt, das ist dabei total egal, denn das Konzept hinter beiden ist das selbe.
Wahlweise sieht es genauso wieder aus, wenn diese Informationen auf dem Bildschirm angezeigt werden sollen. Woher kennt der Renderer die Haarfarbe des Modells, wenn er sie nicht abfragen kann?

Zitat von »BlueCobold«

Problem ist aber, dass man oft gar nicht rundrum kommt, weil gewisse Eigenschaften von gewissen Objekten eben von außen beeinflussbar sein müssen.

Meiner Erfahrung nach muss man das sehr viel seltener, als man vielleicht denken mag.

Zitat von »BlueCobold«

Wie ändere ich sonst die Elemente meiner Menü-Klassen, den Text in meinen GUI-Elemente, [...]

Ja, das sind natürlich alles potentielle Anwendungen. Allerdings ändern sich die Elemente eines Menüs tatsächlich wohl relativ selten und auch der meiste Text in einem GUI ist in der Tat statisch. Gut möglich, dass es tatsächlich eine bessere Lösung wäre, die Elemente bzw. den Text einfach bei der Konstruktion des Objektes festzulegen, hängt aber natürlich von der konkreten Anwendung ab. Das Problem ist, dass es keine allgemeine Antwort, wie ein alternatives Design ohne Getter und Setter prinzipiell aussieht gibt. Die konkrete Lösung hängt immer vom konkreten Problem ab. Aber was beispielsweise den Text von GUI Elementen angeht, so wird man möglicherweise sowas wie einen Setter haben. Getter braucht man dann imo aber schon wieder nicht. Mein D3D GUI System beispielsweise, speichert überhaupt nur direkt das Layout der Glyphen in den UI Objekten und überhaupt keine semantische Information über den Text. Denn der Text muss ja von irgendwo herkommen, die semantische Information steckt also schon dort und gehört auf keinen Fall in die UI Objekte...

Zitat von »BlueCobold«

[...] die maximalen Lebenspunkte einer Spielfigur, die Haarfarbe einer Spielfigur [...]

Maximale Lebenspunkte und Haarfarbe würde ich jetzt mal eher als Kandidaten für unveränderliche Attribute sehen.

Zitat von »BlueCobold«

[...] die Position eines Objekts in der Welt, etc pp?

Ja, da braucht man möglicherweise einen Setter, aber vermutlich keinen Getter. Oder umgekehrt.

Zitat von »BlueCobold«

Ob die Methode dabei "changeHairColor" oder "setHairColor" heißt, das ist dabei total egal, denn das Konzept hinter beiden ist das selbe.

Prinzipiell ja, wobei ich changeHairColor() bevorzugen würde. Da wohl die meisten non-const Methoden per Definition in irgendeiner Form den Zustand des Objektes verändern, ist es natürlich schwer, überhaupt klar abzugrenzen, was man nun als Setter bezeichnet und was nicht. Spätestens wenn man aber Getter und Setter für ein logisches Attribut hat, hat man imo ganz klar ein Designproblem.

Zitat von »BlueCobold«

Woher kennt der Renderer die Haarfarbe des Modells, wenn er sie nicht abfragen kann?

Hängt davon ab wie das Objekt gerendert wird. Aber in der Regel hast du Objekte, die sich selbst rendern, daher brauchst du auch hier wieder entweder nur einen Getter oder nur einen Setter, auf keinen Fall aber beide.

Zitat von »dot«

Getter braucht man dann imo aber schon wieder nicht. Mein D3D GUI System beispielsweise, speichert überhaupt nur direkt das Layout der Glyphen in den UI Objekten und überhaupt keine semantische Information über den Text. Denn der Text muss ja von irgendwo herkommen, die semantische Information steckt also schon dort und gehört auf keinen Fall in die UI Objekte...

Ohne Getter kannst Du aber auch die Elemente nicht in einem Editor zusammenstellen, denn dieser könnte die Werte ja nie wieder auslesen.
Sehr kritisch auch bei Labels, die ihren Inhalt ändern können müssen, bei Eingabefeldern mit Default-Wert, etc.

Zitat von »dot«

Maximale Lebenspunkte und Haarfarbe würde ich jetzt mal eher als Kandidaten für unveränderliche Attribute sehen.

Unveränderlich nur bedingt, denn man muss dieses Maximum ja von Außen festlegen können, sonst kannst du nirgends verschiedene Gegner entwerfen.

Zitat von »dot«

[...] die Position eines Objekts in der Welt, etc pp?

Ja, da braucht man möglicherweise einen Setter, aber vermutlich keinen Getter. Oder umgekehrt.[/quote]Wenn das Modell sich selbst rendern kann, dann braucht es keinen Getter. Aber dann ist es automatisch ein ModelView, was auch nicht immer sonderlich cool ist. Wahlweise hat man dann eventuell ein Problem, dass Projektile oder andere Spieler/NPCs sich nie auf dieses Objekt hin bewegen könnten, weil sie die Position ja nicht abrufen können.

Zitat von »dot«

Spätestens wenn man aber Getter und Setter für ein logisches Attribut hat, hat man imo ganz klar ein Designproblem.

Sehe ich nicht so. Es ist dann halt ein semantisches oder Anforderungs-Problem, weil die Eigenschaft von außen abrufbar und veränderbar sein muss. Ich glaube an kein Spiel, wo es solche Objekte nicht gibt. Außer alle Werte sind hardcoded oder direkt per Hex-Editor geschrieben. Alles andere würde irgendeine Art Objekt fordern, wo die Werte gelesen und gesetzt werden können. Das wären dann zusätzlich unnötige Container-Klassen, die nur für die Konfiguration zusammengeschustert werden und den Code unnötig aufblähen würden.

Zitat von »dot«

Hängt davon ab wie das Objekt gerendert wird. Aber in der Regel hast du Objekte, die sich selbst rendern, daher brauchst du auch hier wieder entweder nur einen Getter oder nur einen Setter, auf keinen Fall aber beide.

Wenn Du das hast, sprich einen ModelView, dann heißt das aber auch, dass Du das Modell nicht verändern kannst, während es sich rendert. Parallelität ausgeschlossen, weil Seiteneffekte es unmöglich machen würden.


Generell stimme ich Dir schon zu, dot, aber wenn man anfängt die wildesten Spagate zu machen, weil man Setter und Getter umgehen will, dann wird das Ergebnis noch deutlich hässlicher, als wenn man sie einfach verwendet hätte.