Patrones utilizados e informes técnicos

Entre los patrones que hemos utilizado para resolver el problema de diseño que se nos planteaba con el juego escogido, se encuentran los siguientes:

INFORME TÉCNICO 1------------------------->

Asunto: Distintos tipos de cartas

Resumen de la solución: Utilizar un PD Plantilla
Factores causantes:
Al tener tres tipos distintos de cartas (CartaAsesino, CartaHabitacion, CartaArma) debemos de distinguir cómo estarán repartidas las cartas entre los jugadores, y el estado de esas cartas.


Solución:
Utilizamos este patrón porque tenemos que distinguir especialidades (CartaAsesino, CartaHabitacion, CartaArma) de un mismo producto (Carta) para poder repartirlas adecuadamente. Por tanto, en las tres especialidades utilizamos el mismo método obtenerCartaSobre().


Motivación:
El patrón plantilla es ideal en éstas ocasiones en las que tenemos que distinguir entre distintas especializaciones en un mismo método. Con esto conseguimos que al añadir una nueva especialización, las demás especializaciones sigan estables.


Cuestiones sin resolver:

Alternativas consideradas:
Podríamos integrar los métodos dentro de cada especialidad, pero esto podría producir que la clase se volviera inestable al añadir una especialidad.



INFORME TÉCNICO 2------------------------->

Asunto: Problema con la suposición y la acusación
Resumen de la solución: Utilización de un PD Estrategia
Factores causantes:
Un jugador podrá realizar una suposición a lo largo de la partida, en el que pronunciará un ASESINO, un ARMA y una HABITACIÓN, pero la única condición es que lo haga dentro de una habitación. Sin embargo, el jugador podrá realizar una acusación con las mismas características que la suposición (sólo una), pero podrá hacerlo en cualquier casilla del juego.



Solución:
Creación de una interfaz con un método proposición que se encarga de realizar la acusación o suposición





Motivación:
Podremos proteger ante posibles variaciones y distinguir entre la acusación y la suposición, para que el sistema pueda elegir aquel que le conviene sin necesidad y utilizar según sus necesidades.




Cuestiones sin resolver:

Alternativas consideradas:
No poner la interfaz descrita anteriormente. Esto provocaría que las clases descritas tengan que comprobar forzosamente si se encuentra en una habitación,…


INFORME TÉCNICO 3------------------------>
Asunto: Encapsular la creación de nuevos tableros.
Resumen de la solución: Aplicación de un PD Fábrica Simple.
Factores causantes:
Encapsular en una clase aparte la creación de tableros.


Solución:

Se ha hecho uso del Patrón de Diseño Fábrica Simple para ello.
Motivación:
Aumentamos la cohesión de la clase de la que se abstrae la creación. Esto hace que la funcionalidad de creación de un tablero se haga más simple.


Cuestiones sin resolver:

Alternativas consideradas:
La alternativa vendría dada por no aplicar dicho patrón. Sin embargo, es conveniente encapsular aparte el proceso de creación de un objeto medianamente complejo.


INFORME TÉCNICO 4------------------------->

Asunto: Encapsular la creación de nuevas cartas.
Resumen de la solución: Aplicación de un PD Fábrica Simple.
Factores causantes:
Al igual que con los tableros, debemos de encapsular la creación de cartas


Solución:
Se ha hecho uso del Patrón de Diseño Fábrica Simple para ello.


Motivación:
Aumentamos la cohesión de la clase de la que se abstrae la creación. Esto hace que la funcionalidad de creación de una carta se haga más simple.


Cuestiones sin resolver:
Añadir nuevas cartas sin eliminar otras podría provocar que el reparto de cartas restantes entre los jugadores no fuese equitativo.

Alternativas consideradas:
La alternativa vendría dada por no aplicar dicho patrón. Sin embargo, es conveniente encapsular aparte el proceso de creación de un objeto medianamente complejo.



Bueno, pues ahí hemos dejado los informes técnicos que hemos hecho a día de hoy.