Anregung für Klassendesign

[stahli]

Ich hatte meinen Beitrag vorhin verworfen, aber da Du von vorn anfangen willst:

Das wichtigste ist m.E. erst mal, dass Du GUI und BL trennst.
Also alles, was Du überlegst und in Klassen abbildest sollte sich auf reine Daten/Objekte beziehen.

Die Darstellung in einem Formular solte da erst mal noch keine Rolle spielen. Wenn Du das sauber einhältst wird Dein Projekt besser wartbar und scalierbar bleiben.

So kannst Du ein komplettes (virtuelles) Projekt in BL-Klassen definieren.

Die Darstellung und Bearbeitung im Formular wäre ein davon völlig losgelöstes (bzw. parallel zu entwickelndes) Thema. Natürlich brauchst Du eine Schicht dazwischen, die beide Seiten verbindet.

Der Aufbau der BL-Klassen ist dann eher Geschmacksache und von der Zielstellung des Projektes abhängig.
Grundsätzlich würde ich die Position einer Figur in Figur.x und Figur.y speichern. Das irgendwo in einem Array abzulegen würde vielleicht Sinn machen, wenn man extrem schnell Berechnungen mit den Berechnungen durchführen will und der Weg über die Figuren zu langsam wäre - aber normalerweise wäre das sicher nicht sinnvoll.

Auch ob man eine Figur in ein Feld einfügt (Owner) oder in das Spielfeld (und die Beziehung zu den Feldern explizit verwaltet) oder ob man jeder Figur ein Spielfeld und ein Feld zuweisen will hängt wohl von der Zielstellung ab.

Ich habe in meinem letzten Projekt jedenfalls nicht Owner benutzt um die Beziehungen abzubilden da dadurch in der Summe ziemlich viel Zeit verbraucht wurde (Observer), die ich lieber anders nutzen wollte.

Auch wo Du MoveTo implementierst musst Du vom Einzelfall entscheiden.

Wichtig ist jedenfalls, alles möglicht gut vonenander zu entkoppeln - sowohl die GUI von der BL als auch die Klassen untereinander.

Wenn Du irgendwann denkst, FigurA bräuchte jetzt mal schnell die dritte Figur auf Feld123 ... hmmm... ok, dafür muss die Figur mal schnell wissen, wie ein Feld aufgebaut ist und dessen Figursammlung durchsuchen ... dann solltest Du stutzig werden.

Und wenn Du in der Richtung weiter denkst wirst Du irgendwann auf Interfaces kommen.
Das ist aber ein weiteres Thema (für mich auch ein recht neues)...

Weiterhin wichtig ist die Persistenz der BL-Objekte. Wenn Du ein Spielfeld hast und darauf Felder und darauf Figuren, dann sind das Objekte mit (Speicher-)Adressen. Wenn Du den Zustand speicherst (z.B. in einer XML-Datei) und später wieder lädst, dann liegen die Objekte natürlich an ganz anderen Adressen im Speicher. Somit brauchst Du eine Möglichkeit, die früheren Beziehungen ("Figur134 hat Figur345 als Freund") wieder herzustellen. Daher müssten die Objekte eine ID erhalten, über die sie identifizierbar sind und über die auch Verweise wieder hergestellt werden können.
Gleiches gilt natürlich, wenn Du nicht alle Objekte gleichzeitig im Speicher halten willst oder kannst bzw. vielleicht über mehrere Clients auf den gleichen Datenbestand zugreifen möchtest (ich weiß, wovon ich rede ).

Fazit: Möglichst klare Klassen bauen, die möglichst wenig voneinander abhängen und die Objekte mit Id´s ausstatten. So wirst Du am weitesten kommen.