Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
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.
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?
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Also würdest du da relativ wahllos neue Klassen einführen?
Hängt natürlich sehr vom zweck und ziel ab.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".
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
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??
Warum sollte ein AnimatedModel auch irgendein dateiformat kennen?
Warum sollte ein AnimatedModel auch irgendein dateiformat kennen?
Wenn es das einzige Dateiformat ist welches unterstützt werden soll dann: Warum nicht?
Werbeanzeige