6.10 OOD: Client

In Kapitel 6.1.2 habe ich die Entscheidung für das MVC begründet. Hier beschreibe ich die technische Umsetzung. Die gesamte Applikation bis ins Detail in UML zu modellieren, wäre nicht nur praxisfern, sondern ein Unterfangen, bei dem ich vermutlich nicht in drei Monaten fertig würde. Daher beschränke ich mich auf eine Generalisierung der Komponenten und die Abläufe der Ereignisse, da diese bei jeder Maske in der gleichen Weise ablaufen.

Für die Anzeige der Spieldaten musste ich mir etwas überliegen, denn eine komponentenbasierte Umsetzung wäre bei großen Spielflächen zu einem Speicherdesaster geworden, da jede Komponente einiges an Daten im Speicher verbraucht. Bei einem Spielfeld von 50x100 Feldern, wären allein für die Anzeige der Oberfläche 5000 Komponenten nötig. Dazu kämen noch zehntausende Komponenten für die Einheiten und Gebäude der Spieler. Diese Anzahl an Komponenten zu verwalten, würde die Applikation sehr langsam machen, weshalb ich das Bild komplett erzeuge und nur die Koordinaten der anklickbaren Objekte abspeichere. Bei einer Änderung (z.B. Abgeben eines Befehls) erzeuge ich das Bild neu, das geht sehr schnell und ich habe nur eine Swing-Komponente, die ich in einer ScrollPane anzeige. Die Schleife, in der die Koordinaten gespeichert werden, kann durch Speicherung in Baumstrukturen beschleunigt werden, wenn die Anzahl der Koordinaten zu groß wird. In dieser Version wird es aber nur eine einfache Schleife sein, denn die Schüler sollen keine perfekte optimierte Applikation bekommen, sondern sie selber optimieren.