Patrones de diseño para sistemas de reglas?

Como un proyecto rápido y divertido, intenté escribir un juego de solitario. Pero al escribir los sistemas de reglas, me sentí sucio , porque mi código se sentía completamente desestructurado e inextensible , principalmente porque mi lógica de juego era un código completo de espagueti.

Me he encontrado con este problema antes, y siempre me siento incómodo al escribir esta parte de mi programa, así que me preguntaba, ¿hay alguna práctica recomendada cuando se trata de definir reglas en un juego ?

No creo que haya una solución única ya que muchas cosideraciones provienen del problema particular.

Puede usar el patrón Controlador de vista de modelo: esto mueve (limita) su problema a "cómo implementar un comportamiento en el controlador", un comportamiento que siempre sigue las reglas.

A menos que estemos hablando de reglas muy simples, la forma en que las organices plantea un problema de expresividad . Siempre enfrenta las demandas conflictivas de ser simple (estructurado) y ser expresivo (escribir reglas divertidas).

El uso de MVC simplifica su trabajo porque el modelo formaliza un estado, es decir, el contexto en el que se aplican las reglas.

Dicho esto, puede resultarle útil implementar el Controlador utilizando el patrón de Estrategia y / o el patrón de Estado para componer un comportamiento complejo en términos de comportamientos intercambiables más simples. Un patrón de cadena de responsabilidad puede ayudarlo a expresar reglas, mientras que una máquina de estado debe usarse con cuidado porque su "estado" se superpone parcialmente al significado del modelo de "estado".

Usar el patrón de Comando dentro del Controlador puede ser útil tanto para reducir las resposibilidades del Controlador (el Comando sabe cómo manejar el modelo) como para facilitar la adición de las funciones de deshacer / rehacer en el Controlador.

En cualquier caso, debe intentar utilizar los patrones de diseño como guía: son útiles para evitar reinventar la rueda, especialmente la rueda cuadrada, pero no la solución de cada problema consiste en un montón de ruedas (redondas) juntas.

No estoy seguro de ser mejor o incluso bueno, pero generalmente uso el patrón Observador . Funcionó bastante bien para mí.

A menos que haya hecho el trabajo muchas veces antes, siempre terminará con un código de espagueti. En realidad, en este punto, recién has comenzado: lo que tienes es el borrador de una especificación preliminar. Echa un vistazo a algunos de los otros consejos aquí y haz una reescritura seria. Y luego un poco más de reescritura, y luego ... Personalmente, nunca estoy seguro de si tengo mi código en una forma realmente excelente o simplemente me canso de reescribirlo, pero parece que finalmente lo hago bien.

Aborde el problema desde dos extremos. Intente que el diseño general tenga sentido y elija piezas pequeñas que se encarguen de tareas simples y que sean correctas. Luego, intenta avanzar desde ambos extremos hacia el centro. Y luego trabaje desde el centro hacia los dos extremos. Luego de arriba hacia abajo, luego de abajo hacia arriba. Luego repite todo el proceso.

Esencialmente, lo que tienes es una colección de clases. Considere la clase A. Si la clase A está bien construida, las clases que la usan funcionarán automáticamente mejor, por buenas o malas que sean. Si la clase A usa bien las clases, esas clases usadas harán más, por buenas o malas que sean. Organice sus clases lo mejor que pueda, luego asegúrese de que cada una sea la mejor clase posible.

Es importante hacerlo lo más correcto posible. Un código incorrecto te perseguirá hasta el día que lo tires. Con el software, un poco de pulido extra siempre vale la pena. (A menos que nadie termine usando el código ...)

Para resumir: revisa los consejos reales dados en las otras respuestas, luego reescribe tu código hasta que obtengas algo que te guste.