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


12

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 .


1
Maximiser l' encapsulation et minimiser le couplage
John McDonald

Réponses:


2

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.


2

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.


1
Pouvez-vous faire un exemple?
Gustavo Maciel

vous pouvez créer un observateur pour chaque règle, puis les attacher à l'état du jeu. après chaque tour, l'état du jeu appelle tous les observateurs pour vérifier si l'une de ces règles est appliquée.
Ali1S232

0

À 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.


Donc votre réponse est fondamentalement "lisez les autres réponses et faites du code propre ou vous regretterez" ...
kaoD

@kaoD: Oui. Mais aussi: votre première tentative de codage sera probablement indésirable. (Si ce n'est pas le cas, vous ne vous poussez pas assez fort.) Il faudra beaucoup de travail pour le rassembler, avec un peu de recherche et beaucoup de réflexion. Ceci est normal lors de l'écriture d'un programme impliqué. Tous les efforts déployés de cette manière permettront d'économiser du temps, des efforts et du chagrin à long terme (si le programme est toujours là à long terme). Et aussi: la POO aide beaucoup si vous pouvez vous y prendre. (Le mieux que je puisse faire sans voir le code.)
RalphChapin

4
Vous rendez-vous compte que vous ne répondez PAS à la question?
kaoD

En fait, indépendamment du fait que le poste de Ralph était techniquement une réponse ou non, je pense que la réponse de Ralph parlait du motif du PO de poser la question en premier lieu. Je crois que cela a beaucoup de valeur pour un codeur qui ne s'est pas rendu compte qu'il est rare que vous conceviez votre code le mieux du premier coup. En outre, il a proposé une approche pour y faire face qui semblait être née de l'expérience de Ralph.
Steve H

@SteveH Je pense que sa réponse est applicable à presque tous les processus de génie logiciel. Vous pouvez le copier et le coller n'importe où et il conviendrait.
kaoD
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.