¿Para usar o no usar el patrón de estado?

Question

Estoy diseñando un juego de pinball para un proyecto Uni en el que se supone que hay 2 modos: el modo de ejecución y el modo de constructor, mediante el cual se puede diseñar/rediseñar el diseño de la máquina.

Mi pensamiento inicial fue el patrón de estado. Sin embargo, me preocupa que la interfaz común entre los estados pueda contratarlos para implementar métodos que no sean apropiados para ese estado.

Por ejemplo. En el modo de constructor sería totalmente apropiado establecer la posición de un parachoques o lo que sea; pero en el modo de ejecución se implementaría como no hacer nada o lanzar una excepción, lo cual parece desagradable, especialmente si hay muchos de esos métodos.

¿Hay un mejor diseño para esto?

Answer 1

Su intuición es correcta. El patrón de estado es útil cuando un programa puede tener muchos estados diferentes, cada uno soportando muchas de las mismas operaciones. Por ejemplo, un programa de dibujo puede tener muchas herramientas diferentes, pero cada una admite operaciones similares, como colocar el lápiz hacia abajo o hacia arriba, y dibujar una línea entre 2 puntos.

En su caso, solo hay 2 estados y no comparten mucho comportamiento. Lo principal que comparten es operaciones de GUI comunes que probablemente ya estén en una biblioteca estándar. Debe asegurarse de que el código para cosas como mostrar los parachoques no esté duplicado, pero puede hacerlo sin el patrón de estado.

Answer 2

Hace un par de años tuve una tarea similar en la universidad.

Yo diría que usar el patrón de estado es excesivo para esto, además de no ser del todo adecuado, como se mencionó anteriormente. Lo que hicimos con esta asignación es:

• Uso algo por encima de los diferentes modos, que permite cambiar entre ellos.
• Cada modo no tiene conocimiento del otro modo, no hacen llamadas entre sí.
• Sin embargo, comparten el conocimiento del modelo (que en su caso sería el tablero de pinball, con posiciones de los parachoques, bolas, etc.), por lo que cuando cambias entre ellos son consistentes.
• En términos de la GUI, cada modo tiene básicamente espacio para hacerlo. Como dices, cada modo tiene diferentes acciones posibles, por lo que forzarlas a compartir las mismas acciones como parte de un patrón de estado es "maloliente".

Básicamente, como se mencionó en otra parte, los dos modos no comparten suficientes elementos comunes para justificar realmente el patrón de estado aquí.

Existe la posibilidad de aplicar el patrón de estado, lo que tendría sentido. Dado que es una tarea de la universidad, es probable que haya crédito por el pensamiento y la justificación detrás de esto. Está relacionado con el "nivel superior" que mencioné anteriormente. En mi experiencia, esto era parte de la GUI que era independiente del modo. Permitió cosas como cerrar la aplicación, abrir configuraciones de pinball anteriores y cambiar de modo. Lo que también podría hacer es mostrar elementos de menú dependientes del contexto. El estado de los menús podría recuperarse del modo actual. Por lo tanto, el modo de generador podría incluir guardar y otras acciones específicas del constructor, y el modo de ejecución podría ofrecer opciones de reproducción/pausa. Si ha pasado el tiempo investigando el patrón de estado, y desea que lo pague, esta sería una opción posible.

P.S.Murray parecía entusiasmado con nuestro uso de los patrones de diseño en ese momento ;-)