✔ Klassenkonzept Schachprogramm

[Snape]

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?

Die Position wird natürlich auf dem Board gespeichert.

Allerdings finde ich auch, dass eine Figur schon wissen sollte, wie sie ziehen darf. Es ist aber an dem Board zu entscheiden, ob sich die Zugmöglichkeiten auf dem Brett auch im Rahmen des legalen befinden, bzw. wenn ja bis wohin.

Ich würde die Klasse Figur anlegen mit Farbe, Typ und Zugmöglichkeiten.

 

[Christian Fein]

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?

Nein der Code liegt nicht im Brett sondern in der Klasse figur.

Die methode createBoard ist eine Faktory, und liegt natürlich nicht in der Board klasse macht da ja auch kein Sinn.

Der Unterschied ist nicht nur semantik. Du wolltest die Logik der Figuren im Brett unterbringen. Ich bringe die Logik in die Figur (wo sie auch hingehört).
Die instantion der Figuren läuft über das Faktory Pattern welche mir die Figuren herrstellt, diese überschreiben die abstracte Klasse figur und somit existiert für jede Figur eine Unterklasse nur mit dem Entscheidenden Vorteil das sich diese nicht über x Files erstrecken, sondern dies an zentraler Stelle in der Factory geschieht.

Weil zu wissen wo oben und wo unten ist, ist keine Eigenart die eine Figur hat. Das ist eine eigenart die das Board hat. Es weiss "wie herum" es gehalten wird.
Gegenfrage:
Das Board bekommt die Meldung welche Figur wohin ziehen soll. Sprich das Board kennt sein Koordinatensystem. Die Figur kennt kein Koordinatensystem, wozu auch. Sie kennt einzig und allein ihre eigene Position. Das Board ist also dafür zuständig wenn ein Move-Request ankommt die Figur zu fragen ob sie diagonal laufen kann. Die Figur sagt ja (siehe anonyme Klassen) . Dann kann das Board entscheiden ob jemand im Weg ist ( denn die Figuren kennen nur sich selber und nicht die anderen Figuren). Sprich das Board muss sowieso Dinge beim Move überprüfen.
Sprich das Board prüft die Dinge, aber fragt dabei jede Figur ob sie überhaupt technisch dafür in der Lage wäre.

 

[Snape]

Gegenfrage:
Das Board bekommt die Meldung welche Figur wohin ziehen soll. Sprich das Board kennt sein Koordinatensystem. Die Figur kennt kein Koordinatensystem, wozu auch. Sie kennt einzig und allein ihre eigene Position.

Sehe ich nicht so. Das Brett muss wissen, wo die Figur(en) steht(en). Siehe oben, es reicht aus, wenn die Figur weiß, welche Farbe sie hat, was für eine Figur sie ist und wie sie ziehen darf.

 

[Christian Fein]

Sehe ich nicht so. Das Brett muss wissen, wo die Figur(en) steht(en). Siehe oben, es reicht aus, wenn die Figur weiß, welche Farbe sie hat, was für eine Figur sie ist und wie sie ziehen darf.

Das habe ich doch geschrieben
Die Figur muss nichts vom Koordinatensystem und den anderen Figuren wissen.

Sie weiss nur welche Farbe sie hat, welche Züge sie machen darf, und wo sie steh. (bei: wo sie steht, kann mann von mir aus auch anders implementieren)

 

[squeaker]

Ich dachte im Schach steht weiß immer unten und schwarz immer oben? Und warum eine Factory für ein Board?

 

[Christian Fein]

Ich dachte im Schach steht weiß immer unten und schwarz immer oben? Und warum eine Factory für ein Board?

Nein eine Figure Factory. Weil ein Board Object nicht dafür zuständig ist Figuren zu erstellen. Ein Board ist ein Board und kein Figurenbastler

Ja aber weisst du ob das Board nicht irgendwann mal drehbar ist? In alle himmelsrichtungen? Vielleicht mal umbauen als 3D Schach?
Spass beiseite: Auch wenn oben immer Schwarz ist, so ist das noch lange kein Grund das eine Figur sowas wissen muss.

 

[Snape]

So ist es. Eine Figur ist eine Figur ist eine Figur. Nimm sie in die Hand - was macht eine Figur aus? Das Brett ist für die Figur vollkommen unwichtig.

Aber was mir immer noch sauer aufstößt:

Sie weiss nur welche Farbe sie hat, welche Züge sie machen darf, und wo sie steht (bei: wo sie steht, kann mann von mir aus auch anders implementieren)

Wo sie steht, kann der Figur sowas von egal sein. Das hat das Brett zu verwalten.

 

[Christian Fein]

Wo sie steht, kann der Figur sowas von egal sein. Das hat das Brett zu verwalten.

Im OOP Sinne geb ich dir recht bei diesem Punkt.

Ich hätte es aus Praktikablen sinne heraus gemacht. Denn ich habe auf dem Board sowieso ein Figur[] und hätte dieses gleichzeitig benutzen koennen um die Standpunkte zu speichern.

Aber seperiert von den Figuren zu speichern ist OOP technisch besser, okido

 

[squeaker]

Warum soll das Brett nicht die Figuren erstellen? Ich erstelle doch auch keine Factory-Klasse für ein Auto, nur weil Autos in Fabriken gebaut werden und sich nicht selber erstellen. Ich würde dem Board die Fähigkeit geben Stellungen auf sich zu stellen - und dazu braucht es Figuren. Wozu dazu eine extra Factory-Klasse bemühen. Diese Fähigkeit Stellungen zu erzeugen ist dann auch beim Wechsel vom Bauern zum ? außer König.

 

[Christian Fein]

Warum soll das Brett nicht die Figuren erstellen? Ich erstelle doch auch keine Factory-Klasse für ein Auto, nur weil Autos in Fabriken gebaut werden und sich nicht selber erstellen. Ich würde dem Board die Fähigkeit geben Stellungen auf sich zu stellen - und dazu braucht es Figuren. Wozu dazu eine extra Factory-Klasse bemühen. Diese Fähigkeit Stellungen zu erzeugen ist dann auch beim Wechsel vom Bauern zum ? außer König.

Ganz einfach um modularität zu erzeugen. Denn mannm will ja die Figuren nicht nur beim Board start erzeugen, sondern auch um ein gespeichertes Spiel zu erzeugen, oder später als erweiterrung was weiss ich über Bluetooth ein spiel aufnehmen usw.

All diese Logik in das Board zu packen, wo es nichts zu suchen hat, resultiert darin das wenn das Programm erweitert wird mit Features die jetzt noch nicht bekannt sind das wie ein dummer refaktoring direkt am Code durchgeführt werden muss.

Durch das Factory Pattern welches mir das Board bestückt kann ich später einfach diese Factory durch eine erweiterte Version tauschen und brauch nicht in der Board Klasse rumwurschteln.

Ausserdem wozu haben wir OOP wenn es nicht benutzt werden soll?

Ich erstelle doch auch keine Factory-Klasse für ein Auto, nur weil Autos in Fabriken gebaut werden

Factory ist der Name eines Entwurfsmuster. Sozusagen allgemein annerkannte Anleitungen zu besseren OOP Code.
Wurde von Gamma usw geschrieben.


http://de.wikipedia.org/wiki/Entwurfsmuster
http://de.wikipedia.org/wiki/Abstrakte_Fabrik