Patrones de diseño

Lista de patrones de diseño. En cada patrón está comentado donde ha sido implementado ó donde lo podríamos incluir.
En caso de que no fuese aplicable en el proyecto también queda indicado.

Índice

Singleton

  • Cargador de módulos: El módulo encargado de la carga de módulos que componen la parte Servidor de nuestra aplicación posee dicho patrón. Hemos pensado que el cargador debe ser único (y por consencuencia una sóla instancia accesible) para restringir la posibilidad de que más cargadores formen parte de la aplicación y se carguen módulos repetidos.

State

  • Juego del Ascottergories: La simulación de la maquina de estados que representa al juego del Ascottergories (tanto en el cliente como en el servidor) se presta a la aplicación de un patrón State. Cada estado del servidor es una clase que implementa IEstado y a donde llegan los eventos de la partida. Por su parte el codigo de cada evento se encarga de informar sobre el siguiente estado del juego.
  • Juego del Pictionary: el sistema de pintado en el juego del Pictionary se acomoda de forma natural a una máquina de estados, representada con el patrón State. Las diferentes acciones del usuario (pinchar con el ratón, arrastrar el ratón…) tienen acciones distintas según esté el cursor dentro o fuera del lienzo, de si había hecho click anteriormente… cada una de estas situaciones se representa con un estado.
  • Juego Hundir la Flota: los distintos estados de este juego (ubicar barcos, atacar y esperar) deben responder a las mismas acciones del usuario de manera diferente. Para conseguir este objetivo de manera fácilmente mantenible se ha utilizado el patrón State.

Abstract Factory

  • Cargador de módulos: El cargador de módulos se asemeja al patrón factoría ya que es el encargado de crear las instancias de los módulos que componen la aplicación. Para añadir más módulos a nuestra aplicación, solamente haría falta incluir el módulo en la ruta especificada por la jerarquía de paquetes (pincha aquí para ver la jerarquía) y ajustar el archivo de manifiesto. No hay que modificar código del cargador de módulos para que realice la carga.

La factoría abstracta se corresponde con IInicioModulo que tiene diversas implementaciones (una por modulo). Estas factorías generan un unico tipo de objeto que son instancias de IModulo.

Façace

  • Módulo de Juegos: de cara a la implementación de los juegos, el módulo de juegos proporciona una interfaz única para acceder a todo el sistema. Dicha interfaz permite acceder a la base de datos, enviar mensajes a los usuarios y guardar un registro de eventos, sin que la implementación de los juegos deba conocer la existencia de los módulos de base de datos, módulo de comunicaciones ni módulo de log.

Template method

  • Partida abstracta: la implementación de un juego concreto pasa por extender la clase Partida. La clase Partida contiene la funcionalidad común a todos los usuarios, pero en muchas ocasiones es necesario abstraer el funcionamiento del juego concreto. Para ello se realizan llamadas a métodos que deben ser redefinidos por el desarrollador del juego concreto (algunos de estos métodos son abstractos, otros tienen una funcionalidad por defecto). Estos métodos definen una plantilla que establece el punto de enganche del framework.

Observer

  • Receptores de datos: el uso del patrón observer permite que diversas clases puedan recibir notificaciones sobre el estado de los jugadores en el modulo de comunicaciones. Se reciben notificaciones en las salidas de los jugadores y ante recepciones de datos y los "observadores" pueden consultar el nuevo estado del ModuloDeComunicaciones (que consiste en datos sobre los jugadores)