Architecture MVC pour un Bomberman

Bonjour,
Ayant de gros doutes j'aimerais vous demander vos avis,
voici pour moi à quoi doit ressembler l'architecture en question:

Vue:
L'affichage de l'écran

Contrôle:
La saisie des évènement ainsi que les fonctions timée (la boucle principale du programme en somme)

Modèle:
Touts les objets et leurs attributs


Par contre pour ce qui est du déplacements (surtout la génération de la direction je ne sais pas trop, ça irait de paire avec la collisions de plus)

Voilà si quelqu'un pouvait me donner son avis
Merci d'avance

La vue concerne l'IHM, donc toutes les communications bi-directionnelles entre l'utilisateur et la machine : écran, clavier, souris, etc.

Je ne suis pas sûr (je n'ai jamais fait de MVC) mais il me semble que :

- vue : interface utilisateur - programme.
- modèle : stockage des données
- contrôleur : traitement des évènements récupéré par la vue et des données.

Les collisions sont à faire côté contrôleur.
Les déplacements sont à faire des 3 côté :
- récupérer l'évènement clavier (vue)
- traiter l'évènement et voir s'il n'y a pas collision (contrôleur)
- stockage d'information dans le modèle (ex : position finale)
- affichage (vue)

EDIT : grillé par cob59^^

ah moi aussi je pensé que c'était plus logique les évènement dans la partie vue ^^
ça me rassure je ne suis pas le seul à penser ainsi

mais honnêtement ça me fait bizarre pour le contrôleur, comme je l'ai actuellement définit c'est juste un concentré de méthode qui à la base auraient très bien leur place dans le modèle
est-ce normal?

edit : exemple:
la méthode de génération de direction et celle de mouvement, elles sont logiquement liée aux classes des "personnages"

Le modèle concerne uniquement le stockage des données.

Ainsi tu peux très facilement passer d'un stockage de donnée en mémoire vive à un stockage de données dans un fichier ou dans une BDD voir même un stockage sur un ordinateur externe.

Tu peux aussi très facilement modifier la manière dont tes données seront enregistrer : en clair, crypté, formaté, binaire, ....

Il suffit juste de remplacer les classes 'Modèles' et de ré-implémenter les fonctions de bases.

Mais le traitement des données, c'est au contrôleur de le faire.

enfaîte pour le principe j'ai bien compris, mais disons que j'ai un cas que je ne sais pas vraiment me décider, je vous l'explique si ca ne vous ennui pas trop

dans un bomberman il y a plusieurs type de génération de direction :
manuel (avec clavier)
ia des petits monstres (différent niveau)
ia des boss (en 2 phases)

la première chose à laquelle j'ai pensé c'est au pattern strategy, sauf que pour moi je l'aurais mit au niveau de la classe "character" classe mère de monstres et bombermans, hors il faudrait que ce soit dans le contrôleur, mais comment faire pour pouvoir bien choisir un type de génération par "character" différents?

voilà si vous avez des idées je suis preneur, et si j'ai mal expliqué dite le moi ^^

Salut,

En gros, c'est pourtant simple :

Tu as un monstre (dans le business), un controleur de monstre (dans la partie controleur) qui controle... le monstre

C'est le controleur de monstre qui (se fait aider pour... déterminer) détermine la stratégie à utiliser en fonction du monstre utilisé ;)

Idéalement, le controleur utilise une fabrique (de stratégies) en lui envoyant le monstre qu'il controle et la fabrique lui renvoie, en retour, la stratégie correspondant au type de monstre qu'on lui a passé ;)

Oki merci, je trouvais ça moins naturel mais bon quand il faut séparer en couches il faut séparer ^^
Merci d'avoir pris le temps de me répondre :)

dis toi que, de toutes manières, tu seras toujours gagnant à respecter un principe de base de la programmation structurée : celui de la responsabilité unique!!!

Si tu donnes la responsabilité à ta classe Monstre de gérer ses stratégies d'attaque, tu ne pourras plus lui en donner d'autre, vu qu'il doit garder une responsabilité unique...

Or, tu es largement en droit de t'attendre à ce qu'un monstre fasse "autre chose" que de gérer sa stratégie d'attaque ;)

Tu auras peut etre l'impression de faire exploser le nombre de tes classes, mais, si tu arrives à faire en sorte que chaque classe ait une responsabilité unique et clairement limitée, tu pourras faire évoluer ton projet dans "toutes les directions" sans craindre, à un moment ou un autre, d'introduire une régression ;)

Il y a une relation étroite entre les stratégies que tu peux décider d'avoir et les monstres qui les utilisent au niveau du modèle, mais c'est au niveau du controleur que la relation doit être faite, et donc, il devient normal de se dire que c'est au controleur du monstre que doit revenir la responsabilité de mettre les deux en relation ;)

De cette manière, tu pourras, en outre, ajouter d'autres stratégies (qui n'ont pas forcément le but d'attaquer), utilisées par d'autres controleurs (qui prennent le relais du monstre quand tu décides par programmation de faire en sorte que le monstre n'attaque pas) sans t'inquiéter d'introduire des régressions ;)

Responsabilité unique hein, j'en prend note ^^
Je vais pouvoir passer à la vitesse supérieure :P
Merci pour tout ^^

Citation:

---

Envoyé par Celes_Vongola

Responsabilité unique hein, j'en prend note ^^
Je vais pouvoir passer à la vitesse supérieure :P
Merci pour tout ^^

---

Tout à fait...

C'est un principe qui dit que si une classe ou une fonction a plus d'une responsabilité, c'est, très certainement, qu'elle en a trop ;)

Cela permet de garder un code court et simple ;)

Après, il "suffit" de se mettre d'accord la "granularité" de la responsabilité ;)

Mais, si tu as une fonction (ou une classe) qui doit:

1. prendre une entrée utilisateur
2. créer une connexion à un serveur
3. générer une requête à envoyer au serveur
4. envoyer la requête
5. obtenir la réponse
6. traiter la réponse
7. réagir en fonction de la réponse du serveur
8. afficher le résultat à l'utilisateur

tu te rendras rapidement compte que, si tu dois créer une seule fonction qui contient la logique de toutes ces étapes, tu obtiendras une fonction "kilométrique", très difficile à lire (et encore plus à modifier) à laquelle tu n'osera pas toucher,tellement tu auras peur de casser "quelque chose".

De plus, une telle fonction serait très difficile à réutiliser, ne serait-ce que à cause de sa spécificité :aie:

Par contre, si tu crée une (voir plusieurs) fonction(s) (ou classes) qui prennent chacune une étape en charge, tu te retrouveras avec 8 fonctions (ou peut etre meme plus ;)) qui seront beaucoup plus faciles à corriger séparément en cas de besoin, et que tu pourras même envisager de réutiliser.

Bien sur, si tu as une fonction qui doit, au final, effectuer les neufs étapes en question, rien ne t'empêche de la créer, mais ce sera sous une forme proche de

Code:

---

1 2 3 4 5 6 7 8 9 10 11

void maFonctionQuiEnFaitTellement() { EntreeUtilisateur in = prendreLEntreeUtilisateur(); ConnexionServeur conn = creerConnexion(); Requete request = creerRequete(in); envoyerRequete(request, conn); Resultat result = obtenirReponseDuServeur(); ResultatFinal fin = traiterResultat(result); reagirAReponse(fin); afficher(); }

---

De cette manière tu sais exactement ce qui est fait à quel moment, et comme ;)

Bien sur, ce n'est pas le seul principe à garder en tête, surtout dés que l'on décide de développer avec un langage orienté objets ;)

Oui, la partie conception d'un langage objet est bien plus poussé, mais c'est tellement plus naturel de penser objet ;)
Et quand j'y pense j'avais codé un bomberman en c, et des fonctions ou structures kilométriques j'en avais ^^
Tout ce que j'avais envie de faire c'était tout recommencer comme mon code s'encrassé :lol:

je n'ais pas eu le temps de le poster tout à l'heure, mais est ce que mon diagramme actuel est dans le bon état 'esprit? ou je me suis quand même tromper :lol:

page 1&2: modèle
page 3: vue et constantes
page 4: contrôleurs
http://myreader.toile-libre.org/inde...nom=Diagramme1

Supprimes déjà cet horrible "Objects" que je ne saurais voir ;)

L'utilisation d'un "God Object" s'avère rarement être une solution rentable à long terme, ne serait ce que parce que cela fini par créer une hiérarchie de classes monolithique, très difficile à faire évoluer ;)

De même, l'énumération decorElements me met particulièrement mal à l'aise, dans le sens où cela laisse entrevoir le fait que tu envisages très sérieusement de l'utiliser pour obtenir du RTTI (RunTime Type Information) :aie:

Si tu pars dans cette direction, ton code deviendra rapidement ingérable car il sera rempli d'équivalent à

Code:

---

1 2 3 4 5 6 7 8 9 10

if(ptr->decorType() == ground) { static_cast<Ground*>(ptr)->doSomething(); } else if(ptr->decorType() == INDESTRUCT_WALL) {   static_cast<IndestructWall*>(ptr)->doSomething(); } /* ... */

---

Tu devrais, au lieu de t'appuyer sur ce genre d'énumération, t'astreindre à la discipline de travailler avec de visiteurs / observateurs / médiateurs, cela participera bien mieux au respect du premier principe que j'ai mis en avant dans mes interventions précédentes ;)

De plus, si je comprend la raison des constantes dans Header, je ne comprend pas pourquoi tu voudrais y mettre les énumérations :aie:

En effet, d'après ce que je déduis de ton diagramme, Header (que je nommerais plutot ViewOptions ;)) a pour principal objectif de regrouper les différentes options propres à l'affichage...

Il n'a, a priori, aucun besoin de connaitre les couleurs, les directions ou encore le type des éléments du décors ;)

Ce n'est qu'une première analyse et il y aurait surement d'avantage à en dire, mais je vais éviter de te matraquer trop vite, en plus, je ne suis pas au mieux de ma forme ce soir :aie:

Mais, au moins, tu as déjà quelque pistes d'améliorations ;)

Merci pour ta réponse ^^
Enfaîte les énumérations il faut avouer que je ne mettais pas poser la question, ce sont des restes de mon programme, mais j'avais que quand j'ai créé des classes qui correspondaient à ces énum j'ai eu un doute sur leur utilité

le header (nom absolument sans intérêt je dois bien avoué) été pour réunir toutes les constantes que j'allais utilisé, mais la encore je crois qu'il ne sera pu nécessaire et je devrai plutôt le séparer en fonction de l'endroit où j'en aurais besoin

en gros le header vestige de mon vieux programme en c, n'as pas ça place ici ^^

pour ce qui est du god object, j’avoue que l'idée n'était pas de moi, j'ai vu un projet bomberman où ils l'avaient fait, chose que je ne voyait pas trop l'intêret mais je m'était dit que je comprendrais surement après : retiré :ccool:

j'attend avec impatience de savoir si ma logique MVC n'est pas trop loin de ce qui devrait être (et je l'espère ) :)