Sinnvoll ist es sicherlich, Code effizienter und Platz und zeitsparender zu machen wenn möglich.
... die Frage ist, wie viel Programmierzeit du investieren willst, um 2 Millisekunden sparen zu können.
Wenn du dir mal anschaust, wie viele Operationen in der GUI passieren, damit eine einzelne Linie gezeichnet wird, dann werden dir deine Optimierungen relativ sinnlos vorkommen - wie gesagt, so lange du nicht z.B. komplexe mathematische Operationen ausführst.
Und es hängt auch immer davon ab, was hinterher passiert. Ob das Ergebnis meiner Berechnung nun 4 oder 5 Sekunden dauert, ist egal, da die Verwendung der daraus resultierenden Produktionsdaten mehrere Minuten in Anspruch nehmen kann. Selbst wenn durch den Automatismus keine optimalen Daten entstehen, weil nicht jeder mögliche Fall abgedeckt wurde und die Produktion dadurch ein paar Sekunden länger dauert - auch egal. Mit der herkömmlichen Methode saßen Leute teilweise eine halbe Stunde dran und haben womöglich Fehler gemacht beim manuellen Generiern der Operationen, durch die neue Methode drücken sie ein Knöpfchen und haben ein Ergebnis nach wenigen Sekunden ein Ergebnis, mit dem hoqchqualitativ produziert werden kann.
Platz sparender ... nein, überhaupt nicht. Aus der Zeit sind wir seit 30 Jahren raus. Was heute Platz braucht, ist nicht der Code.
Hier ein Beispiel aus dem Jahr 2001. Ein bestimmtes Spiel hat damals 1.5 GB an Platz gefressen. Der Code? 10 MB.
Es ist vollkommen egal, ob deine Jar 2 oder 3 MB groß ist, die JRE alleine braucht schon ein Vielfaches davon.
Edit: Ok, beim RAM Speicher muss man vielleicht etwas aufpassen, aber auch da hat man mittlerweile doch deutlich mehr Freiheiten als noch vor 10 Jahren. Mit solch einfachen Problemen wirst du deinen RAM nicht voll kriegen. Das passiert im Normalfall heutzutage nur noch durch eine Endlosschleife. In anderen Sprachen musst du noch den Speicher nicht mehr verwendeter Objekte freigeben, in Java nicht. In dem Moment, wo auf ein Objekt keine Referenz mehr besteht, kümmert sich der Garbage Collector darum.
Dein Fokus muss darauf liegen, Code wartbar zu machen, dazu gehört unter anderem ihn zu organisieren. Halte zusammen, was zusammen gehört, trenne, was damit nicht direkt was zu tun hat. Die Methoden für dein Spiel gehören zum Spiel, sie in andere Klassen zu verlegen, macht deinen Code nur unwartbarer. Und beim Refactoring wirst du dich unglaublich schwer tun.
Ein klassisches Beispiel für zu trennende Logik sind Datenbankzugriffe. Diese gehören nicht in die Datenklassen. Man stelle sich mal vor, man ändert die DB in ein anderes System: Hölle. Und außerdem ... was hat das verwendete DBMS mit den Datenstrukturen zu tun? Deshalb gehören alle DB-Zugriffe in EINE Klasse, welche dann am Ende die Daten bereitstellt. Ändert man das DBMS, Tabellen oder Spaltennamen, dann muss nur diese eine Klasse geändert werden.
Deshalb ist auch der Punkt mit der Groß-Kleinschreibung so wichtig, wie mihe gesagt hat. Damit erkennst du sofort, worum es sich bei xyz handelt.
Und - wie immer - Dokumentation. Auch wenn eine Methode gut benannt ist (anstatt einfach nur "b()" zu heißen), sollte in der Methodendokumentation stehen, was darin passiert.
Was objektorientiertes Arbeiten angeht ... vergleiche es immer mit dem, was du darstellen willst, das ist ein guter Ansatz.
Wenn du mehrere Spieler in deinem Spiel hast, dann wird ein Array von ints kaum dabei helfen, das darzustellen.
Als erstes erstelle also eine Klasse "Player". Bestimme, was einen Player ausmacht, welche Eigenschaften hat er?
Was er können muss, kommt dann in einem zweiten Moment.
Dann mach das selbe für das "Spielbrett" oder womit auch immer gearbeitet wird. Haben die Felder bestimmte Eigenschaften? Falls ja, dann erstelle eine Klasse "Feld" und leg dort die Eigenschaften fest (falls es sich nur um Koordinaten handelt wie bei Schach, kann man eventuell auch darauf verzichten). Z.B. muss ein Feld eine Spielfigur beinhalten können, es braucht also eine Eigenschaft Spielfigur (ein anderer Ansatz wäre, der Spielfigur zu sagen, auf welchem Feld sie steht).
..... und und und
Deinen Code auf mehrere Klassen aufzuteilen hat mit objektorientiertem Design nichts zu tun, es geht vielmehr darum, dass die Eigenschaften eines Objekts bestimmt und zusammengehalten werden, vom Rest getrennt werden. Damit fängt alles an.
