✔ Klassenkonzept Schachprogramm

Snape hat gesagt.:
Figur als eigene Klasse finde ich auch etwas übertrieben. Ich fragte mich nur, ob es prinzipiell eine Klasse "Figur" geben soll oder ob man sie gleich ins Brett/Board integriert. Gefühlsmäßig würde ich eine Klasse Figur anlegen. Dem Brett würde ich die Stellungskontrolle und Verarbeitung überlassen, also Ziehen, Schlagen mit den dafür notwendigen Überprüfungen. Ob auf dem Zielfeld eine Figur steht, wenn ja, ist es eine Figur der eigenen Farbe oder des Gegners, handelt es sich um den König usw.
Zum Vergrößern anklicken....

Gefühlsmäßig würde ich auch eine Klasse für Figur anlegen - sie aber bei Schach dann verwerfen, da die Funktionalität einer Figur doch arg beschränkt ist. Bei Civilisation (dem Computerspiel) hingegen ist es klar, dass eine Klasse für die Figur existieren muß (und ausserdem eine für das Feld auf dem es steht - diese würde ich beim Schachbrett auch weglassen, da nur die Farbe sich ändert, es aber sonst keine Eigenschaften hat).

Snape hat gesagt.:
Meldekette sehe ich GUI (=Spieler) oder Engine an Board und das Board verarbeitet weiter.
Dahingegen bin ich noch unsicher, wo die Zugliste unterzubringen ist...
Zum Vergrößern anklicken....

Das mit der Meldekette sehe ich genauso. Allerdings würde ich die Zugliste zwischen Spieler (ake Engine oder GUI) und Board legen. Damit bekommt die Zugliste jeden Zug mit und kann das Brett manipulieren. Am Ende des Spieles wechselt die Zugliste in den Bearbeiten/Erklären Modus und erlaubt es dem Spieler der das Bearbeitungsrecht anfordert beliebig in der Partie zurück zu gehen und verschiedene Variationen aufzuzeigen bzw. von einem beliebigen Punkt die Partie wieder vortzusetzen.
Das Board überwacht sozusagen ob die Züge "valid" also korrekt sind, die Zugliste kümmert sich um Beobachter, Chat, Variationen, Beobachtungsmodus usw. (daher ist Zugliste eigentlich ein falscher Name, es sollte mehr die Organisation und Protokollierung sein).
 
Gefühlsmäßig würde ich auch eine Klasse für Figur anlegen - sie aber bei Schach dann verwerfen, da die Funktionalität einer Figur doch arg beschränkt ist. Bei Civilisation (dem Computerspiel) hingegen ist es klar, dass eine Klasse für die Figur existieren muß (und ausserdem eine für das Feld auf dem es steht - diese würde ich beim Schachbrett auch weglassen, da nur die Farbe sich ändert, es aber sonst keine Eigenschaften hat).
Zum Vergrößern anklicken....

Prinzipiell gibt es aber unterschiedliche Zugmöglichkeiten der einzelnen Figuren. Wo sollen die rein?

Das mit der Meldekette sehe ich genauso. Allerdings würde ich die Zugliste zwischen Spieler (ake Engine oder GUI) und Board legen. Damit bekommt die Zugliste jeden Zug mit und kann das Brett manipulieren. Am Ende des Spieles wechselt die Zugliste in den Bearbeiten/Erklären Modus und erlaubt es dem Spieler der das Bearbeitungsrecht anfordert beliebig in der Partie zurück zu gehen und verschiedene Variationen aufzuzeigen bzw. von einem beliebigen Punkt die Partie wieder vortzusetzen.
Zum Vergrößern anklicken....

Eine Navigation durch die Partie/Zugliste sollte m.E. jederzeit möglich sein, Stichwort u.a. Zugrücknahme bei bemerktem Fehler.

Das Board überwacht sozusagen ob die Züge "valid" also korrekt sind,
Zum Vergrößern anklicken....

Das ist eine weitere Frage. Die Engine muss ja sowieso alle legalen Züge bestimmen, oder soll sie diese vom Brett erhalten? Andererseits, wenn die Engine die legalen Züge bestimmt, wird vermutlich dennoch das Brett nicht umherkommen, ebenfalls die legalen Züge zu bestimmen. Damit wäre gewährleistet, dass bei einer Partieeingabe ohne Engine nur legale Züge eingegeben werden können.

die Zugliste kümmert sich um Beobachter, Chat, Variationen, Beobachtungsmodus usw. (daher ist Zugliste eigentlich ein falscher Name, es sollte mehr die Organisation und Protokollierung sein).
Zum Vergrößern anklicken....

Also eine Art GameController. ;)
(Kommt mir irgendwie bekannt vor diese Klasse. ;))
 
Die Zugmöglichkeiten der einzelnen Figuren würde ich in diesem Fall in die Validierung der Züge stecken. Sollte recht kurz und schmerzlos sein.

Das Board hat einen Zug und einen Positionierungsmodus. Der Zugmodus ist für das Spiel und validiert die Züge. Der Positionierungsmodus ist für die Erklärungen und wird von außen gesteuert -> Gamecontroller.

Zugrücknahme jederzeit möglich ist ja nicht ausgeschlossen, sollte aber in einem Turnier nur nach Absprache mit dem anderen Spieler möglich sein und nicht per default.

Im Prinzip muss nur das Board die Regeln können, für die Engine/den Spieler wäre es von Vorteil. Aber prinzipiell kann der Spieler beliebige Züge schicken die dann vom Board überprüft werden. Ist er korrekt, so wird der Zug ausgeführt und der andere Spieler erhält das Zugrecht. Ist er nicht korrekt, so wird er nicht ausgeführt und des Spieler erhält erneut das Zugrecht.
 
squeaker hat gesagt.:
Ich fände das übertrieben. Schach ist nicht so kompliziert, als dass man wirklich jede einzelne Figur eine eigene Klasse geben müsste. Ausserdem wie soll da die Kommunikation gestaltet werden?

Zugbefehl an Figur, die an Board, das an die geschlagene Figur?
oder Zugbefehl an Board, welches die Figur befehligt?
Zum Vergrößern anklicken....

Es wäre aber ooptechnisch sinnvoll.

Die kommunikation erfolgt über die Board klasse.
Die Board klasse sollte nicht wissen wie die figuren laufen, denn das ist kein Bestandteil des Boards.
Jede Figur sollte aber wissen wie sie laufen darf.

Das Board sollte aber wissen ob eine Figur ungehindert da drüber laufe darf.

der Code könnte so aussehen:

Code: 
class Board ...

 public boolean moveFigure(Figure figure, Coordinate target) {
    if( figure.couldReach(target) && 
        (getFigureOn(target).isEnemyTo(figure) == false) &&
        (  clearWay(figure.getPosition(),target) || figure.isJumping) ) {
             figure.setPosition(target);
             Figure enemy = getFigureOn(target);
             if(enemy!=null) 
                         killFigure(enemy);
    } 
}

In diesem Code steckt somit folgende Logik:
Kann die Figur das Ziel erreichen, ist nicht eine eigene Figure auf diesem Zielfeld,
ist der Weg zum Ziel frei oder kann meine Figur zu Ziel springen.
Wenn das gegeben ist dann setze die Figure auf die Position und schlage falls vorhanden
die Gegnerfigure vom feld.


Es gibt also eine ganze Menge was eine Figur über sich wissen könnte.

- wo bin ich
- bin ich ein Springer
- wie laufe ich
- zu welchem Spieler gehör ich
- ist der Übergebene Figure Parameter ein Feind

usw

Das alles in Board zu kapseln wäre, nicht bös sein, ein OO Fehler.

Ein Tip wie mann zu guten Klassen kommt ist die UseCases aufzuzählen und jedes Supstantiv als Object zu sehen.
Use Cases wären in einem Schachspiel:

Ein Spieler meldet sich beim Spiel an. ( Objecte Player, Game)
Die Figuren werden über das Spielfeld verteilt ( Objecte Figure, Board)
Der Spieler 1 bewegt Figure auf Koordinate A4 auf Koordinate .. ( Object Coordinate und Methode move)
Der Weg wird geprüft ob frei von Spielern oder aber die Figur drüber springen kann ( Board#checkWay und Figure#isJumpable)
usw.
 
Das die Figuren OO-technisch Objekte sein müssten, ist eigentlich klar. Die Frage ist ob man mit einer Kanone nach Spatzen schießt. Ich meine ja - andere nein. Das ist sicherlich Geschmackssache. Um es etwas extremer zu gestalten: OO-technisch müßten bei einem GO-Spiel auch jeder einzelne Stein eine eigene Klasse sein, allerdings macht ein Stein während des ganzen Spieles nichts ausser daliegen (er kann nicht gezogen werden) bis er geschlagen wird oder das Spiel endet. Dafür aber dann 360 Einzelinstanzen der Klasse Stein je Ausprägung (Schwarz bzw. Weiß) zu machen ist auch übertrieben.
 
squeaker hat gesagt.:
Das die Figuren OO-technisch Objekte sein müssten, ist eigentlich klar. Die Frage ist ob man mit einer Kanone nach Spatzen schießt. Ich meine ja - andere nein. Das ist sicherlich Geschmackssache. Um es etwas extremer zu gestalten: OO-technisch müßten bei einem GO-Spiel auch jeder einzelne Stein eine eigene Klasse sein, allerdings macht ein Stein während des ganzen Spieles nichts ausser daliegen (er kann nicht gezogen werden) bis er geschlagen wird oder das Spiel endet. Dafür aber dann 360 Einzelinstanzen der Klasse Stein je Ausprägung (Schwarz bzw. Weiß) zu machen ist auch übertrieben.
Zum Vergrößern anklicken....

Ein Object ist keine Kanone. Bei einem Schachspiel in der nacher ein paar Fünfzig Figuren auftauchen macht sich auch das instanzieren der figuren absolut 0,0001 sek bemerkbar ;)
Seid wann ist eine Klasse für ein Object eine Kanone? ;)

Sorry aber es gibt eigentlich absolut keinen Grund weshalb mann gegebene Mittel (Objecte) nicht nutzen soll.
Schau dir mal die Java Klassenlibrary an. Da gibt es eine Klasse die nennt sich Point. Das ist nichts anderes als eine Klasse mit 2 Attributen (X,Y).

Genauso gibt es dort eine Klasse URL welche letztendlich mehr oder weniger einen String erweitert.
Die Klasse Figur hat in einem Schachspiel mindestens 5-6 Methoden die du sonst der Klasse Board zuordnen müsste, obwohl sie dort nicht hingehört.
Sprich es ist OOP-Technisch unlogisch das Board weiss ob diese oder jene Figur springen darf oder nicht. Das muss die Figur wissen.
 
Hab ich nicht bestritten. Blos vielleicht komplizierter zu Programmieren. Für einen Teil der sowieso nie geändert wird (schließlich ändern sich die Schachregeln nicht).
 
Einfache Antwort: wenn es aufwändiger ist, aber keinen zustätzlichen Nutzen bringt, dann keine zustätzliche Klasse (ich weiß, diese Ansicht ist eher Ketzerisch), sonst ja. Eine zustätzliche Klasse später einfügen wenn sie benötigt wird ist nicht so schwer (wenn doch, hätte es von Anfang an eine gebraucht) und Refactoring gehört zum Geschäft.
 
Also ich bin auch für die Version für die Figuren eine eigene Klasse zu machen
Macht das Prgramm einfacher

Class Figur hätte dann locale Variablen für Typ (zb. Turm) und die Farbe, ein Methode um zu ermitteln ob ein Zug erlaubt ist.
public erlaubterzug boolean (int vonx,int vony,int nachx,int nachy,boolean schlage)
die Richtung - den Boolean schlage braucht man zwar nur für den Bauern aber egal :-)
und ein Methode um typ und farbe zu ermiteln

Das Brett währe dann auch eine Klasse mit einem array von Objekten der Klasse Figur -
Die Klasse Brett speichert so die Positionen der Figuren
wobei ich sogar soweit gehen würde und auch eine Intanz der Klasse Figur anzulegen mit dem Typ leeres Feld
so kommt man nur auf 64 Intanzen
Und die Mehoden für die History
Eine wer am zug ist mit Uhr
eine Methode um den Spielstand zu sichern und eine zum laden
hier würde ich sogar xml einsetzen denn dann könnte man das Schachspiel so aufbohren das man
mit anderen online (bzw via email) spielt - man tauscht einfach die xml dateien aus :-)

Der Vorteil den Ich sehe ist das die Klasse Fugur ja ermittelt ob es ein erlaubter Zug ist und das einzige was ich dann beim Brett abfangen müsste währe die Rochade
 
Zuletzt bearbeitet:
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück