Padrões de design para sistemas de regras?

Como um projeto divertido e rápido, tentei escrever um jogo de paciência. Mas, ao escrever os sistemas de regras, senti-me sujo , porque meu código parecia completamente desestruturado e inextensível , principalmente porque minha lógica de jogo era um código de espaguete completo.

Eu já enfrentei esse problema antes e sempre me sinto estranho ao escrever essa parte do meu programa, então fiquei imaginando, existem práticas recomendadas para tentar definir regras em um jogo ?

Eu não acho que exista uma solução única, pois muitas considerações vêm do problema em particular.

Você pode usar o padrão Model View Controller: isso move (confinam) seu problema para "como implementar um comportamento no controlador", um comportamento que sempre segue as regras.

A menos que estejamos falando de regras muito simples, a maneira como você as organiza coloca um problema de expressividade . Você sempre enfrenta as demandas conflitantes de ser simples (estruturado) e ser expressivo (escrever regras divertidas).

O uso do MVC simplifica seu trabalho, porque o modelo formaliza um estado, ou seja, o contexto em que as regras são aplicadas.

Dito isso, você pode achar útil implementar o Controlador usando o padrão de Estratégia e / ou o padrão de Estado para compor um comportamento complexo em termos de comportamentos comutáveis ​​mais simples. Um padrão de cadeia de responsabilidade pode ajudá-lo a expressar regras enquanto uma máquina de estado deve ser usada com cuidado porque seu "estado" se sobrepõe parcialmente ao significado de "estado" do modelo.

O uso do padrão Command no Controller pode ser útil para reduzir as responsabilidades do Controller (o Command sabe como lidar com o modelo) e facilitar a adição das funções de desfazer / refazer no Controller.

De qualquer forma, você deve tentar usar os padrões de design como orientação: eles são úteis para evitar reinventar a roda, especialmente a roda quadrada, mas nem todas as soluções de problemas consistem em várias rodas (redondas) juntas.

Não tenho certeza sobre ser melhor ou até bom, mas geralmente uso o padrão Observer . Funcionou bem o suficiente para mim.

A menos que você tenha feito o trabalho muitas vezes antes, você sempre terminará com código de espaguete. Na verdade, neste ponto, você apenas começou: o que você tem é o rascunho de uma especificação preliminar. Confira alguns dos outros conselhos aqui e faça uma reescrita séria. E depois mais algumas reescritas, e então ... Pessoalmente, nunca tenho certeza se coloco meu código em ótima forma ou fico cansado de reescrevê-lo, mas pareço acertar eventualmente.

Resolver o problema de duas extremidades. Tente fazer o design geral fazer sentido e escolher peças pequenas que lidam com tarefas simples e que as acertem. Em seguida, tente trabalhar o seu caminho de ambas as extremidades para o meio. E depois trabalhe do meio para as duas extremidades. Depois, de cima para baixo e de baixo para cima. Em seguida, repita todo o processo.

Essencialmente, o que você tem é uma coleção de classes. Considere a classe A. Se a classe A for bem construída, as classes que a utilizarão funcionarão automaticamente melhor, por melhores ou más que sejam. Se a classe A usar bem as classes, essas classes usadas farão mais, por melhores ou más que sejam. Portanto, organize suas aulas da melhor maneira possível e garanta que cada uma seja a melhor classe possível.

É importante acertar o máximo possível. O código incorreto o assombrará até o dia em que você o expulsar. Com o software, um pouco de polimento extra sempre compensa. (A menos que ninguém acabe usando o código ....)

Para resumir: confira as orientações reais fornecidas nas outras respostas e reescreva seu código até obter o que deseja.