spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »MasterK«

Für mich klingt das dann eher danach, als würdest du prozedurale programme in klassen verpacken. Klassen allein machen aber objektorientierung noch nicht aus. Viel des genutzten codes liegt doch oftmals sowieso in anderen klassen. Eine "gameobjekt" klasse hat zB nen mesh, aber das ist im allgemeinen ja eine eigene klasse. Ein mesh hat ne textur, im allgemeinen auch eine eigene klasse. Ein gameobjekt hat evtl einen vordefinierten pfad auf dem es sich bewegt. Auch wieder ne eigene klasse. Renderstates, wieder ne klasse. Meistens hast du dann nicht 12 "overhead"-methoden, sondern eher methoden sinnvoll in klassen verteilt dort wo sie hingehören.
Grosse methoden die viel magic code ausführen (welcher dann auch noch dutzende private member ändert) ist schwer zu testen und schwer zu warten. Lieber kleine methoden, die genau eine klar abgegrenzte aufgabe haben. Am allerbesten ist es natürlich, wenn diese methoden dann noch const sind. Die lassen sich dann leicht durch einen unit-test jagen.

Das mag ja alles stimmen, dennoch gibt es immer mal wieder Methoden (wie die typische Lade-Routine von dot), die eben lang sind und sich auch nicht großartig kürzen, sondern maximal aufsplitten lassen. Wenn ich 50 Member aus einer Datei lesen muss, dann muss ich die eben lesen, da macht weitere Kapselung in mehr Klassen irgendwie keinen großen Sinn. Und die Tatsache, dass es eben so viele Member gibt, die mag zwar unschön sein, aber durchaus ihren Grund haben (Configs, Level-Templates, Datei-Bibliotheken, etc, etc).
Wie umgehe ich das? Deine Aussage war ja wie gesagt richtig und ich weiß sehr wohl wie ich OOP aufbaue und dass viele Klassen nur Member enthalten, die eben wieder Klassen sind. Ich habe damit ja nicht erst gestern angefangen, wenn Du Dich erinnern möchtest. Nur gibt Deine Aussage keine Antwort auf meine eigentliche Frage: Wie umgehe ich lange Methoden ohne eine Klasse mit unnötigen privaten Methoden aufzublähen?

Zitat von »BlueCobold«

Nur gibt Deine Aussage keine Antwort auf meine eigentliche Frage: Wie umgehe ich lange Methoden ohne eine Klasse mit unnötigen privaten Methoden aufzublähen?

Ok, nehmen wir uns mal dots methode vor...
Aber wie gesagt... private methoden sind nicht unbedingt "unnötig". Sie splitten ein problem in viele kleine teilprobleme, die für sich natürlich leichter zu testen sind. Aber nun zu dots methoden.
Ganz oben würde ich anfangen, den header-check auslagern. Wird man sicher auch an anderen stellen brauchen, könnte evtl ne statische methode von TowerModelFileFormat sein. Generell würde ich in dieser methode einiges in die klasse TowerModelFileFormat auslagern, da die AnimatedModel klasse offenbar den inneren aufbau von TowerModelFileFormat kennt, was ich eh nicht so gut finde. Die folgende schleife lässt sich sowieso kürzen (um ~5 zeilen), da 0, 1 und 2 natürlich als indizies ansprechbar sind.
Dann kennt das AnimatedModel offenbar seine materials und erstellt GL texturen. Ich finde, das gehört in eigene klassen ausgelagert. Danach kommt irgendwas mit animationen. Wenn man die ganze struktur ändert, kann das natürlich auch in eine eigene klasse.

Problematisch (und das natürlich besonders auch auf deine fragestellung) ist bei der frage nach dem aufsplitten von methoden natürlich immer die tatsache, dass dies oftmals dann auch änderungen im klassendesign nach sich zieht. Wenn man von vornherein eine klasse wie in dots beispiel vorsieht, die zB kenntnisse über das dateiformat hat obwohl es eigentlich nur eine model-klasse ist, dann wirds natürlich schwierig, einfach nur "methoden zu splitten". Nachträglich ist das wohl schwierig. Also sind zu lange methoden eher noch das zeichen dafür, dass deine objektstruktur nicht optimal ist Soll heissen, wenn du nach dem splitten von methoden fragst, dann isses zu spät

Aber natürlich muss man da immer auch den passenden mittelweg zwischen aufwand und nutzen finden.

TowerModelFileFormat ist ein Namespace
Abgesehen davon ist mir, wie gesagt, bewusst dass die Methode nicht ganz sauber ist weil ich das damals schnell einfach so runtergecodet hab (ich hab sie aber gerade deswegen ausgewählt).
vb und ib sind keine guten Namen, das stimmt, in meinem Code verwend ich die Abkürzungen aber durchgehend wenn ich nur schnell wo einen VertexBuffer oder IndexBuffer brauch.

@MasterK:
Also würdest du da relativ wahllos neue Klassen einführen? Beispielsweise eine Klasse für ein Fileformat? Sind für sowas nicht serialize und de-serialize Methoden sinnvoller als unabhängige Klassen, die ein Datei-Format für eine eigentlich ganz andere Klasse beschreiben oder das (de-)serialize übernehmen?
Ich weiß nich, ich find's nicht gut da überall relativ künstliche Klassen zu erfinden, die eher einen geistigen Spagat darstellen als Nachbildungen greifbarer Objekte eines "realen" Modells, nur um de fakto "langwierige" Codes in kürzere zu "designen".

Zitat von »BlueCobold«

Also würdest du da relativ wahllos neue Klassen einführen?

Nicht wahllos

Zitat von »BlueCobold«

Beispielsweise eine Klasse für ein Fileformat?

Hängt natürlich sehr vom zweck und ziel ab.

Zitat von »BlueCobold«

Sind für sowas nicht serialize und de-serialize Methoden sinnvoller als unabhängige Klassen, die ein Datei-Format für eine eigentlich ganz andere Klasse beschreiben oder das (de-)serialize übernehmen?

Ha, jetzt haste dir aber selber ein beim gestellt Genau davon rede ich doch die ganze zeit, methoden sollten genau definierte aufgaben übernehmen, nicht mehr. In dots beispiel macht die methode aber eben deutlich mehr als nur die datei zu laden. Wo wir wieder beim aufsplitten wären...
Ob serialize- und deserialize methoden für eine AnimatedModel-klasse aber das richtige wären, wage ich zu bezweifeln. Denn ein AnimatedModel sollte im allgemeinen ja unabhängig vom dateiformat sein. Du kannst der klasse zwar entsprechende methoden geben, es muss aber idR immer noch eine klasse existieren, die die daten in das korrekte dateiformat übersetzt. Denn das war ja im allgemeinen zuerst da.

Zitat von »BlueCobold«

Ich weiß nich, ich find's nicht gut da überall relativ künstliche Klassen zu erfinden, die eher einen geistigen Spagat darstellen als Nachbildungen greifbarer Objekte eines "realen" Modells, nur um de fakto "langwierige" Codes in kürzere zu "designen".

Im endeffekt kannst du jeden code weit runterbrechen auf kleine klasse und kurze methoden. Man muss natürlich irgendwo einen schlussstrich ziehen.

Und dieser Schlussstrich is bei mir scheinbar an einer anderen Grenze als bei euch

Was die Methode von dot genau gemacht hat, das weiß ich ehrlich gesagt nicht, da ich's nur überflogen hatte und es nach einer reinen Datei-Lade-Routine aussah. Falls da mehr drin war, dann wäre Splittung natürlich sinnvoll.

Ich sehe auch keinen Grund darin, eine Datei-Lade-Funktion in 5 Funktionen aufzuteilen. Warum auch? Diese Teilmethoden könnte ich dann eh nicht alleine aufrufen, sondern nur in Verbindung. Aber dann kann ich auch gleich eine einzige Funktion daraus machen.

Anders sieht es auch, wenn meine Klasse nur dafür zuständig ist, dieses Dateiformat zu laden: Dann könnte man auch eine Funktionen Load() machen, die einen Chunk-Header nach dem anderen liest und je nach Typ z.B. die Funktionen ReadFormatChunk(), ReadDataChunk(),... aufruft.

P.S. Was hat das eigentlich mit UN zu tun??

Zitat von »BurningWave«

Ich sehe auch keinen Grund darin, eine Datei-Lade-Funktion in 5 Funktionen aufzuteilen. Warum auch? Diese Teilmethoden könnte ich dann eh nicht alleine aufrufen, sondern nur in Verbindung. Aber dann kann ich auch gleich eine einzige Funktion daraus machen.

Anders sieht es auch, wenn meine Klasse nur dafür zuständig ist, dieses Dateiformat zu laden: Dann könnte man auch eine Funktionen Load() machen, die einen Chunk-Header nach dem anderen liest und je nach Typ z.B. die Funktionen ReadFormatChunk(), ReadDataChunk(),... aufruft.

Wenn du nochmal genau liest, wirst du sehen, dass wir genau da gelandet sind... Warum sollte ein AnimatedModel auch irgendein dateiformat kennen?

Zitat von »BurningWave«

P.S. Was hat das eigentlich mit UN zu tun??

Nüscht.

Zitat von »MasterK«

Warum sollte ein AnimatedModel auch irgendein dateiformat kennen?

Wenn es das einzige Dateiformat ist welches unterstützt werden soll dann: Warum nicht? Hier zusätzliche Klassen einzuführen nur um das Lesen der Datei zu kapseln wäre imo ineffizient (Zeitverschwendung + erzeugt Overhead da die Daten erst in ein Zwischenformat gewandelt werden müssen). Wenn natürlich mehrere Dateiformate unterstützt werden sollen oder es sonst einen Grund gibt den Ladevorgang zu kapseln ist das aber natürlich sinnvoll.

Zitat von »dot«

Zitat von »MasterK«

Warum sollte ein AnimatedModel auch irgendein dateiformat kennen?

Wenn es das einzige Dateiformat ist welches unterstützt werden soll dann: Warum nicht?

Ich hab ja geschrieben, es hängt vom zweck etc ab. Aber im "idealen" OOP (davon bin ich mal ausgegangen), sollte das model eben das datenformat nicht kennen.

War ja keine kritik an deinem code