Java SchachDesign

[Kuma]

Hey
Also, ich bin gerade dabei Schach in Java zu implementieren und wollte nochmal wegen meines Klassendesigns nachfragen.

[Leider geht keiner von den 7 UML Designer die ich runtergeladen habe>.<]

interface: Chessman <--- AbstractChessman <---

So, da würde mich schon mal interessieren was besser wäre.
Entweder ich schreibe dann noch eine Klasse, welche für alle Figuren gilt, welche sich gerade/diagonal bewegen und Bauer und Springer erben direkt von AbsractChessman.
Oder sollte ich ein weiteres interface definieren in dem ich definiere wie sich etwas bewegt, sprich diagonal, eines für linear und ein jumpInterface.

Das Problem, welches ich dabei sehe ist dann wieder die linear/diagonalen Figuren, mit Interfaces wäre es doch etwas lästig die 4 immer zu implementieren, also tendiere ich da zu meiner Oberklasse für diese vier.

Des weiteren gibt es die Klasse ChessGameBoard, welches so viel wie der Controller ist.
Sowie eine ChessView, welche vorerst mit Buttons bedienbar ist.

Ich hätte gedacht, dass die Logik im ChessGameBoard abläuft, sprich alle überprüfungen ob die Figur wohin springen darf bzw eine andere nehmen.

Wie und wohin eine Figur springen darf wäre dann aber innerhalb der Figurklassen.


Passt das vorerst so oder muss ich noch etwas ändern?

 

[Tumbleweed]

So von der ersten Überlegung her, würde ich wohl im Chessman-Interface eine Methode im Stil

List<ChessField> getPossibleMoveDestinations(ChessGameBoard board);

schreiben, die anhand des aktuellen Spielfelds entscheidet, wohin sich die Figur bewegen kann. Mir würde auf Anhieb nicht einfallen, welchen Vorteil separate Interfaces hätten, denn dass die Figuren sich bewegen können, haben sie alle gemein. Es gibt keine, die sich nicht bewegen kann.
Ich würde deshalb nur die Zielfelder berechnen, weil ich den Weg dahin allein der View überlassen würde. Alternative könnte man natürlich auch List<List<ChessField>> machen, um dann mögliche Zugwege zu übergeben und das aus der View rauszuhalten.

 

[Schaltnetze]

Wenn du was richtig cooles machen willst schau dir mal Graphiti an die haben sogar ein Schach Beispiel als Tutorial
http://www.eclipse.org/graphiti/

http://help.eclipse.org/juno/topic/org.eclipse.graphiti.doc/resources/docu/examples/Chess.htm

Die haben ein git repo wo du das Schach Beispiel runterladen kannst.

 

[Kuma]

@Tumbleweed
Nein, du verstehst nicht ganz.
Das sich die Figuren bewegen können ist klar.
Es geht mir eher darum WIE sie sich bewegen können.
Ein Jumper bewegt sich schließlich nicht so wie die Königin.

Dein Bsp verstehe ich jetzt nicht so ganz.
Aber ich meinte eher so, dass ich den Figurklassen ein Array definiere wie sich eine Figur bewegen darf.

Es würde mich noch interessieren, ob es vielleicht intelligenter wäre dies im Board zu machen?

Zudem wäre die Playerunterscheidung interessant. Wie soll ich die am besten realisieren? Zur zeit habe ich es einfach nur so geplant, dass eben jede Figur mit einer Frabe initialisiert wird und nachdem ein Zug gemacht wurde die Farbe eben wechselt und nur noch die zur verfügung steht.
Ich schätze mal das wird so ganz gut funktionieren, nur ist das in Hinsicht auf OOP bzw Erweiterungen, Netzwerk? praktikabel?.

 

[Tumbleweed]

Es geht mir eher darum WIE sie sich bewegen können.
Ein Jumper bewegt sich schließlich nicht so wie die Königin.

Wie sich eine Figur bewegt, kann theoretisch erst einmal nebensächlich sein, denn was zählt ist, wo die Figur nach ihrem Zug landet, daher List<ChessField> als Liste möglicher Zielfelder. Die genannte Alternative ginge mehr in die von dir angedachte Richtung. Mit List<List<ChessField>> könnte man eine Liste von Laufwegen zurückgeben, die zu möglichen Zielfeldern führen. Ein Springer kann doch in viele Richtungen springen, nicht nur in eine! Viele Figuren können mehr als nur "vorwärts".
Das was du meinst mit "wie sich eine Figur bewegen darf", das muss jede Figurenart wissen, ja, aber das braucht sie nur um in der von mir vorgeschlagenen Interface-Methode ihre möglichen Zielfelder zu ermitteln.

Es würde mich noch interessieren, ob es vielleicht intelligenter wäre dies im Board zu machen?

Bei Server-Client, auf beiden Seiten. Client meldet gewünschten Zug an, Server validiert, ob der Zug erlaubt ist.

Zudem wäre die Playerunterscheidung interessant. Wie soll ich die am besten realisieren? Zur zeit habe ich es einfach nur so geplant, dass eben jede Figur mit einer Frabe initialisiert wird und nachdem ein Zug gemacht wurde die Farbe eben wechselt und nur noch die zur verfügung steht.

Beim Schach gibt es doch nur 2 Farben/Spieler. Daher ist das doch banal. Wer dran ist, sollte das Board entscheiden und nach abgeschlossenem Zug einfach umschalten. Hin und her.

 

[Schaltnetze]

Vielleicht wolltest mir nicht zuhören oder warst zu faul die Links anzuschauen , aber im zweiten Link ist doch ein Klassendiagramm dabei.
Das Board regelt wo die Figur abgestellt werden darf je nach Typ ist das natürlich unterschiedlic, der Figur selber ist das doch erstmal egal .

Wenn du in einer GUI noch highlighten willst, wo die Figur überhaupt hin darf, dann musst du natürlich die möglichen Felder für den Typ zurückgeben.

 

[Kuma]

@Tumbleweed
Also, ja weis schon wie du meinst.
Ich habe es jetzt halt mit einem Mehrdimensionalem bool Array gemacht welches eben zurückgibt wohin er stpringen darf.
Dann naütrlich ob er überhaupt dorthin darf usw.

Okay, wegen den Spielern wollte ich nur sicher gehen.
Jetzt fange ich halt mit weis an, wenn der seinen Zug gemacht hat wird zu SCHWARZ weitergeswitcht und damit darf auf die Schwarzen zugegriffen werden.
Ich schätze mal für Server/Client wird wohl doch eine eigene Player Klasse intelligenter sein, als nur schwarz/weis, obwohl eh der Controller das managen muss.

@Schaltnetze
Doch, doch habs mir angeschaut aber konnte jetzt nicht besonders viel damit anfangen, zumal ich selbst auch etwas machen möchte.
Irgendwie versteh ichs mit den Tiles auch nicht so ganz. Zur Zeit hab ich es nämlich so, dass ich einfach 64 Buttons initialisiere und bei jedem einen Listener registriere und damit umgehe. Mit den Tiles wüsste ich jetzt spontan nicht wie ich regristrieren soll, dass auf ein bestimmtest Tile gedrückt wurde.
Die View muss ich sowieso noch umschreiben ist zur Zeit nur zur Überprüfung meiner Logik da.

 

[Schaltnetze]

Irgendwie versteh ichs mit den Tiles auch nicht so ganz. Zur Zeit hab ich es nämlich so, dass ich einfach 64 Buttons initialisiere und bei jedem einen Listener registriere und damit umgehe. Mit den Tiles wüsste ich jetzt spontan nicht wie ich regristrieren soll, dass auf ein bestimmtest Tile gedrückt wurde.
Die View muss ich sowieso noch umschreiben ist zur Zeit nur zur Überprüfung meiner Logik da.

Das wäre ja ein anderes Problem, aber du solltest erst mal ein Domain Model haben um ein Schachspiel abzubilden und es immer schlecht das über die GUI abbzubilden.