Diseñando objetos para un juego de ajedrez en Java

Question

Estoy diseñando un juego de ajedrez en Java (sin AI, solo controlado por el usuario), y todavía me estoy acostumbrando a OOP. Tengo dos preguntas.

estaba pensando de tener, además de Game, Cell, Piece y Board objetos, un objeto de Player.

Mi pregunta es, ¿realmente lo necesito? Por supuesto que no es necesario, pero ¿se considera que una opción es un mejor diseño? Por un lado, parece que un jugador es útil para contener información sobre piezas de jugadores y debe contener métodos como takeTurn(). (Para mi implementación, también quiero hacer un seguimiento de todos los movimientos posibles, así que tendré un método getAllMoves()). Por otro lado, ¿Player no es simplemente una reorganización de los datos existentes? Cada Pieza ya tiene una indicación de a qué jugador pertenece. Y como mi juego no contiene AI, podría tener sentido que takeTurn() pertenezca a Game, en lugar de Player. Por primera vez, quizás Player solo tenga el método getAllMoves(), que utiliza sus datos pero no toma medidas.

La segunda pregunta, relevante si la respuesta a la primera pregunta es sí, es ¿cómo organizo las relaciones entre los objetos? getAllMoves() tomará como entrada una matriz de celdas; pero parece extraño que la clase Player dependa del hecho de que sus celdas coinciden (son un subconjunto de) las celdas pasadas como entrada. Se sentiría más bien si los datos divididos por jugador de las células se mantuvieran juntos con la matriz de todas las celdas de la Junta, y se actualizaran juntos, garantizando así que estén de acuerdo. Por supuesto, la garantía de que están de acuerdo existiría de cualquier manera, pero parece que el objeto Player no debería estar al tanto de la garantía que está teniendo lugar en el objeto Board.

¿Cómo manejo estas preguntas?

Gracias!

Answer 1

En mi humilde opinión tener un objeto Player es un buen diseño.
Incluso puede refinarlo más tarde en una interfaz y tener una implementación de AIPlayer y HumanPlayer.
Hoy solo necesita el método getAllMoves pero más tarde es posible que necesite más. Tener un objeto te ayudará a extender tu habilidad con el jugador.

Para su segundo punto, no estoy seguro de que el Reproductor implemente directamente el método getAllMoves().

Lo delegaría en el objeto ChessGame. Jugador va a tener en este caso una referencia al juego y los delegados de los getAllMoves llaman a esta instancia del juego, así:

pseudo-código :)

bueno juego, ¿cuáles son los movimientos disponibles para esta pieza ?

Answer 2

La cuestión de si necesita un objeto 'Player' - pregúntese si este objeto tiene alguna interacción/relación con otros objetos en su sistema. Además, ¿tiene algún dato o información de estado que desee registrar? Puedo pensar en un par de cosas que puede que quiera hacer un seguimiento de un jugador: piezas capturadas, tal vez una puntuación.

Por cierto, podría ser una buena idea construir un modelo de objetos para visualizar cómo se relacionan los objetos entre sí. Esto también le dará una mejor idea de las interfaces entre los objetos y los métodos requeridos.

Answer 3

¿Está familiarizado con UML y más específicamente con Diagrama de casos de uso y Secuencia? Esto suena como un ejercicio de modelización y sería una buena idea buscar también la noción de modelo de dominio.

Los actores de la aplicación de uso como Player suelen transponerse como clases (también conocidos como sustitutos). Se pueden determinar otras clases comenzando con un diagrama de secuencia aproximado para cada caso de uso con su clase Actor en un lado y una clase de sistema global en el otro.

Esta clase de sistema se puede descomponer gradualmente a medida que avanza por los diferentes mensajes. Si un método/messsage no está directamente en una sola instancia de una clase y sus atributos/estado interno, existe la posibilidad de que pertenezca a otra parte (por ejemplo, una clase BankAccount no tiene la misma responsabilidad que una clase BankAccountManager). Puede agrupar los métodos de acuerdo con la naturaleza y debería ver aparecer otras clases.

A partir de ahí debe ser un caso simple de determinar si existe alguna relación de 1 a 1, uno a muchos y muchos a muchos entre ellos. En Java, estos estarán representados por instancias únicas o Listas y direccionalidad (¿la clase A sabe acerca de la clase B o es una calle de sentido único?) Se representa por la presencia o ausencia de referencias dentro de las clases respectivas.

P.S: Tenga en cuenta que lo que describo vagamente es un enfoque de la metodología, mientras que UML simplemente se contenta con describir un sistema desde diferentes puntos de vista.