✔ Klassenkonzept Schachprogramm

Wir sind ja immerhin schon bei einer Klassenhierarchie angekommen. Figur als Oberklasse zu den einzelnen Ausprägungen. Die Frage ist, wie gestaltet man schwarz und weiß?

Die spezial-Regeln kann man ja als ein Regel-Objekt während der Kreation der Instanz der Figur übergeben und somit quasi die Ausprägung bestimmen. Beispiel: en-passant Schlagen.
 
>class Figur {
>char farbe,type;
>// A - H wird zu 10 - 80 und 1 -8 wird addiert C4 ist dann 34

Das erinnert an die Fernschach-Notation und dürfte praktikabel sein

>public boolean zugerlaubt(int von,int nach,boolean schlage);

Gemäß Codestyle und Codeconventions eher

public boolean IsLegalerZug(int von,int nach,boolean schlage);

oder

public boolean IsLegalMove(int von,int nach,boolean schlage);

Mit dem boolean schlage bin ich noch nicht sicher. Bei von-nach muss evtl. berücksichtigt werden, ob eine eigene/gegnerische Figur "im Weg" steht.

>public char getfarbe();

Alternativ:
public boolean IsColorWhite();

>// Typ B=Bauer T=Turm S=Springer L=Läufer K=König M=Königin

>Leider fangen Ja König und Königin mit K an darum bei Königin ein M für Majestät :-)

Ähem, die "Königin" heisst auf Deutsch "Dame" und auf Englisch Queen. ;)
(Englisch: Bauer=Pawn, Läufer=Bishop, Springer=Knight [Abk.:N], Turm=Rook, Dame=Queen, König=King)

>und die Umwandlung in Integerwerte für die Felder um Zugrichtungen besser bewerten zu können
von C4 ein schräger Zug für den Läufer währe ein vielfaches von +-11 und +- 9

Man beachte, dass ein Bauer in eine beliebige Figur umgewandelt werden kann, außer in einen König.
Und man beachte auch, dass bei den Berechnungen evtl der Brettrand überschritten wird...
 
Hab nicht so genau drauf geachtet, aber dafür habe ich ja
>public char getfarbe();

Alternativ:
public boolean IsColorWhite();
Zum Vergrößern anklicken....

vorgeschlagen. :-p
Was ja quasi implizit bedeutet, dass die Farbe eine boolean Instanzvariable sein sollte. ;)
 
Seid ihr jetzt für eine Klasse die alle Figuren repräsentiert oder für je eine Klasse pro Figurentyp.

Ich finde eine Figur sollte feststellen können, ob etwas im Weg steht (und was). Dann könnte eine König-Klasse selbständig die Rochade ausführen und man bräuchte nicht die Krücke worüber ein Teil der Bewegungsregeln über das Brett, ein Teil über die Figur geregelt wird.
 
squeaker hat gesagt.:
Ich finde eine Figur sollte feststellen können, ob etwas im Weg steht (und was).
Zum Vergrößern anklicken....
Das würde ja bedeuten, dass jede Figur-Instanz auf alle anderen Figuren Zugriff hat: finde ich nicht so gut. Diese Logik sollte man vielleicht doch der Brett-Klasse überlassen.
 
Nun boolean isWhite() bedeutet nicht automatisch das eine boolsche Membervariable genutzt werden muss

Ich würde auch nicht jede Figur als eigene Klasse definieren. Wenn dann höchstens als anonyme implementation.

Wenn das Board aufgebaut wird:

Code: 
public abstract class Figure {
    public abstract boolean couldMoveDiagonal();
    public abstract boolean couldHitDiagonal();
    public abstract boolean couldMoveHorzontal();
    public abstract boolean couldMoveVertical();
    public abstract boolean couldJump();
    public abstract int getMaxMoves();
}


.... /// das Board wird aufgebaut:

private void createBoard()   {   
    int a = 0;
    for(int i = 0 ; i < 16; i++) {
          // BAUERN
         figures[a++] = new Figure() {
                public boolean couldMoveDiagonal() { return false; }
                public boolean couldHitDiagonal() {return true; }
                public boolean couldMoveHorzontal() { return false; }
                public boolean couldMoveVertical( return true; }
                public boolean couldJump() {return false};
                public int getMaxMoves() {return 1; }                
          }
          figures[i].setWhite(  (i < 8) ? true : false; );
          figures[i].setPosition( i % 16 , ( i < 8) ?  1: 6; );                     
    } 
    // TÜRME 
     for(int i = 0; i < 4; i++ ) {
          figures[a++] = new Figure() {
                public boolean couldMoveDiagonal() { return false; }
                public boolean couldHitDiagonal() {return false; }
                public boolean couldMoveHorzontal() { return true; }
                public boolean couldMoveVertical( return true; }
                public boolean couldJump() {return false};
                public int getMaxMoves() {return -1; }                
          }
          figures[i].setWhite(  (i < 4) ? true : false; );
          figures[i].setPosition( i % 4, ( i < 4) ?  1: 6; );
     } 
}

Damit werden die Bauern und die Türme schon richtig instanziert und gleich auf
die Positionen verteilt, und deren Farbe bestimmt.
 
Warst du nicht immer für viele Klassen? Eigene Klassen für jeden Figuren-Typ ist sehr praktisch, schließlich kann jede Klasse dann ganz einfach bestimmen, ob der Zug legal ist und es ist übersichtlich. Wenn sich eine Figur nicht richtig bewegen läßt, so liegt das an der entsprechenden Implementation und viele Klassen sind ja (siehe oben) kein Problem.

Schließlich gilt ja: Ein Bauer ist eine Figur, aber nicht jede Figur ein Bauer.
Bei der Farbe können wir uns evtl. drüber streiten - aber auch da würde es Sinn machen, schließlich kann sich ein schwarzer Bauer nur nach unten, ein weißer nur nach oben bewegen.
Figure ist natürlich abstrakt, da es keine allgemeine Figur gibt.

Die Positionierung muß auch eine beliebige Positionierung der Figuren erlauben (was aus dem obigen Codeschnipsel nicht ausgeschlossen ist) für: a) gespeicherte Spiele, b) Aufgaben, c) Erklärungen und Variationen

Die Feststellung ob eine Figur im Weg steht, gelingt natürlich nur über das Brett auf dem die Figur steht - allerdings sollte der König feststellen können ob die Rochade geht und der Bauer ob sein Zug 2 vor gültig ist indem er das Brett befragt ob etwas da steht (und vielleicht noch welche Farbe es hat). Die Logik der Rochade sollte auf jeden Fall nicht im Brett abgefangen werden sondern vom König durchgeführt werden.
 
Zuletzt bearbeitet:
squeaker hat gesagt.:
Warst du nicht immer für viele Klassen? Eigene Klassen für jeden Figuren-Typ ist sehr praktisch, schließlich kann jede Klasse dann ganz einfach bestimmen, ob der Zug legal ist und es ist übersichtlich. Wenn sich eine Figur nicht richtig bewegen läßt, so liegt das an der entsprechenden Implementation und viele Klassen sind ja (siehe oben) kein Problem
Zum Vergrößern anklicken....
Das sind doch viele verschiedene Klassen. Nur mit Vorteil die verschiedenen Zugmöglichkeiten der Figuren am einem Platz festgelegt werden.
Modularität ist weiterhin gegeben da die abstrakte Klasse Figur ohne probleme ausgetauscht werden kann.
Die anonyme Implementation der Klasse gibt hier nur die Spielregeln der betreffenden Figur wieder. Somit benötigen wir 1 Klasse Figur die entscheiden kann ob sie auf das
Betreffende Feld laufen darf oder nicht.

squeaker hat gesagt.:
Schließlich gilt ja: Ein Bauer ist eine Figur, aber nicht jede Figur ein Bauer.
Bei der Farbe können wir uns evtl. drüber streiten - aber auch da würde es Sinn machen, schließlich kann sich ein schwarzer Bauer nur nach unten, ein weißer nur nach oben bewegen.
Figure ist natürlich abstrakt, da es keine allgemeine Figur gibt.
Zum Vergrößern anklicken....

Die Figur selber sollte aber nicht wissen ob sie nach oben oder unten laufen kann. Denn wo oben und wo oben ist, hat die Figur nicht zu entscheiden. Die Figur weiss das sie vertikal laufen darf. Und macht 1 Schriff vertikal. Ob das nun nach oben oder unten ist das weiss das Board besser.
Das Board ist ja auch jener der der Figur sagt zu welchem Zielfeld sie sich bewegen soll. Dann kann die Figur anhand ihrer Attribute entscheiden ob sie so laufen darf oder nicht.

Die Positionierung muß auch eine beliebige Positionierung der Figuren erlauben (was aus dem obigen Codeschnipsel nicht ausgeschlossen ist) für: a) gespeicherte Spiele, b) Aufgaben, c) Erklärungen und Variationen
Zum Vergrößern anklicken....

Der obere Schnippsel ist der Boardaufbau bei Spielbegin. Das bei einem gespeicherten Spiel keine Figuren neu instanziert werden, sondern sämmtliche Objecte aus einem Object Stream kommen ist klar.
 
Das Konzept der anonymen Klassen entspricht aber wieder fast dem, dass die komplette Logik im Board liegt. Die Figuren "verlassen" das Brett ja nicht, d.h. sie werden nur von der Brett Klasse benutzt. Damit liegt der komplette Code wieder im Brett was ich oben vorgeschlagen habe (und dann aufgrund deiner Argumentation verworfen habe bzw. mich der Mehrheit hier angeschlossen habe). Der Unterschied ist sematik - mehr nicht.

Warum soll die Figur nicht wissen, dass sie nach oben oder nach unten laufen kann? Wo wird die Position der Figur gespeichert?
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück