Modèles de conception pour les systèmes de règles?

Comme projet amusant et rapide, j'ai essayé d'écrire un jeu de solitaire. Mais pour écrire les systèmes de règles, je me sentais sale , parce que mon code était complètement déstructuré et inextensible , principalement parce que ma logique de jeu était du code spaghetti complet.

J'ai déjà rencontré ce problème auparavant et je me sens toujours gêné lors de l'écriture de cette partie de mon programme.Je me demandais donc s'il existe des meilleures pratiques éprouvées en matière de définition de règles dans un jeu .

Je ne pense pas qu'il existe une solution unique car beaucoup de cosiderations proviennent du problème particulier.

Vous pouvez utiliser le modèle Model View Controller: cela déplace (limite) votre problème vers "comment implémenter un comportement sur le contrôleur", un comportement qui suit toujours les règles.

A moins que nous ne parlions de règles très simples, la façon dont vous les organisez pose un problème d' expressivité . Vous êtes toujours confronté aux exigences contradictoires d'être simple (structuré) et expressif (écrire des règles amusantes).

L'utilisation du MVC simplifie votre travail car le modèle formalise un état, c'est-à-dire le contexte dans lequel les règles sont appliquées.

Cela dit, vous pouvez trouver utile d'implémenter le contrôleur en utilisant le modèle de stratégie et / ou le modèle d'état afin de composer un comportement complexe en termes de comportements commutables plus simples. Un modèle de chaîne de responsabilité peut vous aider à exprimer des règles alors qu'une machine d'état doit être utilisée avec précaution car son "état" chevauche partiellement la signification du modèle "état".

L'utilisation du modèle de commande dans le contrôleur peut être utile à la fois pour réduire la responsabilité du contrôleur (la commande sait comment traiter le modèle) et pour faciliter l'ajout des fonctions annuler / rétablir dans le contrôleur.

Quoi qu'il en soit, vous devriez essayer d'utiliser les modèles de conception comme lignes directrices: ils sont utiles pour éviter de réinventer la roue, en particulier la roue carrée, mais toutes les solutions au problème ne consistent pas en un tas de roues (rondes) assemblées.

Je ne suis pas sûr d'être meilleur ou même bon, mais j'utilise généralement le modèle Observer . Cela a assez bien fonctionné pour moi.

À moins que vous n'ayez fait le travail plusieurs fois auparavant, vous vous retrouverez toujours avec du code de spaghetti. En fait, à ce stade, vous venez juste de commencer: ce que vous avez est le brouillon d'une spécification préliminaire. Découvrez quelques-uns des autres conseils ici et faites une réécriture sérieuse. Et puis un peu plus de réécriture, et puis ... Personnellement, je ne suis jamais sûr si je reçois mon code en très bonne forme ou si j'en ai juste marre de le réécrire, mais je semble bien le faire finalement.

Résolvez le problème de deux côtés. Essayez de donner un sens à la conception globale et de choisir de petites pièces qui gèrent les tâches simples et de les faire correctement. Essayez ensuite de vous frayer un chemin des deux extrémités vers le milieu. Et puis travaillez du milieu dos vers les deux extrémités. Puis de haut en bas, puis de bas en haut. Répétez ensuite tout le processus.

Essentiellement, ce que vous avez est une collection de classes. Considérez la classe A. Si la classe A est bien construite, ses classes qui l'utilisent fonctionneront automatiquement mieux, qu'elles soient bonnes ou mauvaises. Si la classe A utilise bien les classes, ces classes utilisées feront plus, qu'elles soient bonnes ou mauvaises . Alors organisez vos cours du mieux que vous pouvez, puis assurez-vous que chacun est le meilleur cours possible.

Il est important de bien faire les choses. Un mauvais code vous hantera jusqu'au jour où vous le jeterez. Avec un logiciel, un peu de polissage supplémentaire est toujours payant. (À moins que personne ne finisse par utiliser le code ....)

Pour résumer: consultez les conseils réels donnés dans les autres réponses, puis réécrivez votre code jusqu'à ce que vous obteniez quelque chose que vous aimez.