✔ Klassenkonzept Schachprogramm

Aber einfach nur ein Pattern zu verwenden um es zu verwenden ist komisch:

Aus dem Desing Patterns Compagnion:
"You should consider using a Factory Pattern when:
- a class can't anticipate which kind of class of objects it must create
- a class uses its subclasses to specify which object it creates
- you want to localize the knowledge of which class gets created."

So viel ich sehe passt KEINER der Punkte oben, warum also ein indirektes Konzept mit einer Factory (die auch nur von dem Brett gebraucht wird) wenn es keine Vereinfachung bringt?
 
squeaker hat gesagt.:
Aber einfach nur ein Pattern zu verwenden um es zu verwenden ist komisch:

Aus dem Desing Patterns Compagnion:
"You should consider using a Factory Pattern when:
- a class can't anticipate which kind of class of objects it must create
- a class uses its subclasses to specify which object it creates
- you want to localize the knowledge of which class gets created."

So viel ich sehe passt KEINER der Punkte oben, warum also ein indirektes Konzept mit einer Factory (die auch nur von dem Brett gebraucht wird) wenn es keine Vereinfachung bringt?
Zum Vergrößern anklicken....

Habe doch geschrieben wieso. Modularität.

doch diese Punkte passen:
- you want to localize the knowledge of which class gets created.
- a class can't anticipate which kind of class of objects it must create

Denn die Figuren sind von verschiedenen Klassen (und auch hier ist modularität gewünscht), und diese werden in der Faktory erstellt.

Nochmal langsam:

Wir sind uns einig das die BoardFiguren unterschiedlicher Weise zusammengestelllt wird. Entweder in Ausgangsbasis bei einem Spiel begin:
Oder beim laden eines gespeicherten Spiels.

Also gibt es schon 2 verschiedene Arten wie das Board zusammengestellt wird.
Willst du diese Beiden Arten der Figuren zusammenstellungen mit in das Board packen?

Was passiert wenn irgendwann das ganze um eine andere Art der Figuren Erstellung erweitert werden soll?
Zum Beispiel die Möglichkeit Ausgangsituationen von Historischen Schachspielen über das Internet einzuladen?

Mit deiner Variante müsstest du die Klasse Board erweitern. Sprich im Code herumändern der auch noch für andere Dinge zuständig ist.
Mit meiner Variante brauch ich nur diese Factory austauschen. Das heisst mann muss keinen Code rumrefactoren der mit dem was ich ändern will eigentlich nichts zu tun habe.
 
Auf dem Brett werden Standart-Figuren in unterschiedlichster weise, von AUSSEN beschrieben und aufgestellt. Das Board bekommt also den Befehl: "POSITIONIERE BAUER E4" usw. Damit werden vollständige Stellungen beschrieben und man kann einfach Figuren setzen (z.B. bei einer Netzwerksession baut ein Lehrer eine Stellung Live auf dem Brett auf und Erklärt sie). Dafür dann für jede einzelne FIGUR die gesetzt wird eine Factory aufzurufen und das Brett auszutauschen ist gelinde gesagt Schwachsinn. Die Standardstellung kann, muß aber nicht auf dem Brett implementiert werden und ist ein Spezialfall einer beliebigen Stellung. Dazu wird z.B. einfach dem Brett das Kommando "CREATE START" geschickt und es Initialisiert sich mit der Standardaufstellung.

Der wichtige Punkt ist, da das ganze ja auch eine Leher-Schüler-Funktion und eine Funktion zum erstellen von Aufstellungen beinhalten soll wäre es Richtig schlecht für jede einzelne Hinzugefügte Figur eine Factory bemühen zu müssen. Ob man jetzt die Figuren ausserhalb oder innerhalb des Brettes erschafft ist egal - ich bin immer noch für den Ansatz der für jeden Figurtyp eine Subklasse von Figur hat.
 
squeaker hat gesagt.:
Stellung Live auf dem Brett auf und Erklärt sie). Dafür dann für jede einzelne FIGUR die gesetzt wird eine Factory aufzurufen und das Brett auszutauschen ist gelinde gesagt Schwachsinn
Zum Vergrößern anklicken....
Bevor du mir Schwachsinn vorwirfst schau dir lieber nochmal mein Code an, und les die Beiträge. Wie du auf die Idee kommst das die Factory für jede einzelne Figur aufgerufen wird weiss ich auch nicht. Aber das du wenn du mit solchen Vorstellungen an meine Vorschläge rangehst kann das auch nichts werden.
Die Factory gibt ein Figur[] zurück.

Und Board ruft diese Klasse auf um die Figuren zu erhalten. Die Figuren sind richtig gesetzt die wissen wo sie stehen.

Woher weiss das Board wer seine Figuren setzt? Das wird dem Board mitgegeben. Sprich es wird dem Board das Richtige Object mitgegeben welches weiss woher es die Daten bekommt.

Pseudo Beispiel
Code: 
public class Chess {
   
    .... 
    switch(irgendwas) {
       case newstart:
          figureFactory = new DefaultFigureFactory();
       break;
       ....
       case bluetooth: 
          figureFactory = new BluetoothFigureFactory();
       break;
   
        case savedGame:
          figureFactory = new FileFigureFactory(new File(...) );
        break;
    }  
   board = new Board(figureFactory);
}


..............

public class Board {
       private FigureFactory figureFactory;
       private Figure[] figures;

       public Board(FigureFactory figureFactory) {
              this.figureFactory = figureFactorry;
        }
       public void init() {
             figures = figureFactory.createFigures();             
       }
}

..... irgendwo die paint Methode des Boards 
public void paint(Graphics graphics) {
    for(int i = 0; i < figures.length; i++) {
        Point point = figures[i].getPosition();
         paintFigure(figures[i].getType(),point);
    }
}

Du willst die Geschichte von aussen setzen. Das bringt dir keinen Vorteil. Denn du müsstest sowieso Konnektoren schrieben die sich an den jeweiligen Use-Case zur Board Generierung anpasse müssten.
 
War doch hoffentlich nur ein kleines Missverständnis, was nicht ausarten sollte.

Zum Board:
M.E. sollte es Figuren platzieren und ausgeben können (welche Figur auf welchem Feld steht). Evtl. noch, welche Farbe gerade am Zug ist und wo sich gerade ein en-passant-Feld befindet bzw. ein Feld sollte diesbezüglich ein boolean-Flag haben. Mit ein paar Goodies evtl. die aktuelle Brettposition als EPD-String ausgeben.
Richtig/Falsch? Habe ich etwas vergessen?

Und da der Thread ja inzwischen schon gut aufgebläht ist, wie wäre es, wenn wir ein Projekt aufsetzen und das Klassenmodell schon mal aufbauen? :)
 
Nochmal zu oben. Wie sieht dein Verhalten des Boards aus, wenn sagen wir mal eine Stellung mit 5 Figuren kreiert wird. Wohlgemerkt - eigentlich wird erst eine Stelung mit 1 Figur geschaffen, dann eine hinzugefügt usw.

Mein Board hat übrigens andere Eigenschaften als deines. Was du beschreibst macht bei mir eine andere Klasse - ein Gamecontroller (siehe weiter oben im Thread). Das Board interagiert nur mit dem Gamecontroller und kümmert sich nur darum, dass nach den Regeln gespielt wird - mehr nicht. Die Steuerung kommt von aussen. Der Gamecontroller kennt die Spieler, die Zuschauer, loggt das Spiel, kann das Brett in einen nicht-Spiel-Modus versetzen in dem Stellungen aufgebaut werden können, kennt einen Besprechungsmodus (wichtig für das Loggen von Variationen) usw.
An die Kontrolle docken dann die Spieler an (und die Zuschauer). Erst diese Klasse kümmert sich dann um Netzwerk, Schachengine, GUI, Bluetooth usw.
So kann dann bei eintsprechendem Design die Spielkontrolle auch für andere Spiele verwendet werden.
 
Zuletzt bearbeitet:
squeaker hat gesagt.:
Nochmal zu oben. Wie sieht dein Verhalten des Boards aus, wenn sagen wir mal eine Stellung mit 5 Figuren kreiert wird. Wohlgemerkt - eigentlich wird erst eine Stelung mit 1 Figur geschaffen, dann eine hinzugefügt usw.
.
Zum Vergrößern anklicken....

Schau in den Code oben (wenn ich mir schon die Mühe mach, les ihn bitte).

Dem Board ist es absolut schnuppe ob
figureFactory.createFigures() ein FigureArray[16] oder ein FigureArray[5] herausgibt.

Es stellt die Figuren so wie die FigureFactory es der Figure sagt wo sie steht.

wieder siehe beispielcode
Code: 
  for(int i = 0; i < figures.length; i++) {
        Point point = figures[i].getPosition();
         paintFigure(figures[i].getType(),point);
    }

ob die Schleife 32 mal oder 6 mal läuft ist dem Board schnuppe. Das braucht das Board auch nicht zu interressieren, wozu auch.

Wenn du einen Gamecontroller bastelst der wiederrum von allem eine Ahnung hat ( Netzwerk, Spieler, Spielmodi (Pause usw) ) dann wirst du niemals einen universell einsetzbare Klasse bauen können.
Es ist nicht sinnvoll viel in eine Ultimative Mittelpunkt klasse zu stecken, ob das Board oder Gamecontroller ist.
Jede Klasse soll eine Aufgabe beherrschen, und sowenig wie möglich Abhängigkeiten heraufbeschwören.
Natürlich muss es eine Klasse geben die das Spiel steuert, sprich die verschiedenen Modies wie Pause (bzw Besprechungsmodus) Start usw steuert. Aber wozu soll diese Klasse auch noch die Ganze Spielervewaltung und zudem Netzwerk steuern.
Das macht doch kein Sinn. Züge über das Netzwerk verteilen macht ein Connector der auch nichts anderes macht als den anderen Spieler (und evtuelle Zuschauer) zu informieren und mit ihnen daten auszutauschen.
Der Gameengine kann letztendlich egal sein wie die anderen Teilnehmer angesprochen werden (ob Bluetooth, ob Socket, ob Webservice, ob sowieso ).
Haust du das ganze mit in die Gameengine hast du wiederrum das Problem das du kein modularen Code erzeugst.
Halte die Klassen doch klein und spezialisiert.
 
squeaker hat gesagt.:
Dann lass uns doch mal definieren was das Ziel ist.
Zum Vergrößern anklicken....

Wie wäre es mit einem Schach spielenden Schachprogramm? ;)

Erstes Etappenziel: Ein Schachprogramm, welches zunächst für jede beliebige (eingebbare) Stellung alle legalen Züge ermittelt und anzeigt. Und meinetwegen jeweils die Stellung und die legalen Züge als Debuginformationen ausgeben.

[Hier Platz für weitere Etappenziele (=Meilensteine)]
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück