Discussion :

[tristan_m]

Bonjour à tous,

Afin d'appliquer un peu les design patterns, je viens de réaliser un casse brique basique (pas d'intro, d'ennemis, d'effets, etc...).

Comme structure de base, je suis parti d'un MVC. Avec du recul, j'ai la nette impression que toutes les données du modèle(Model) sont dupliquées dans la vue.

J'ai fait le diagramme de classes pour clarifier un peu mes propos (aprés l'avoir codé, je sais c'est dans l'autre sens normalement ) :

Il manque pas mal de relations, notamment des liens sujet/observateur un peu partout, mais c'était juste histoire de donner l'archi générale.
... Qui doit être assez catastrophique d'ailleurs .

Je pense que je m'y suis mal pris, et je pense que mon controleur devrait surement être un peu plus impliqué, mais je vois pas comment (la il gère les actions de la souris, les transistions entre les états début/en cours/pause/fin et les initialisation/sortie du jeu).

Un des intérêts de MVC étant de pouvoir changer de vue "comme de chemise", je m'étais mis en tête de pouvoir faire une vue 2D puis une vue 3D sans changer le modèle.
Mais je ne vois pas comment faire ça sans faire cette duplication modele/vue

Donc les questions (finalement ):
Est ce que MVC est destiné à "dupliquer" tous ces objets?
Est ce que ma représentation de MVC est fausse (plus que probable) et dans ce cas comment la rectifier?
Est ce que MVC n'est pas indiqué pour cette appli (ça serait étonnant mais pourquoi pas) ou peut être y a t-il un modèle plus approprié?

Merci d'avance!

PS: Je précise au cas où que c'est pour du C++

[benohite]

salut,

je vais essayer de t'éclairer un peu bien que je ne sois pas un expert du design pattern MVC

Est ce que MVC est destiné à "dupliquer" tous ces objets?

Non du tout, il sert simplement à changer "de vue comme de chemise" comme tu l'as dit

Est ce que ma représentation de MVC est fausse (plus que probable) et dans ce cas comment la rectifier?

En tout cas il y a un gros problème dans ton diagramme, le mvc a pour but de séparer complètement le modèle de la vue. Or Tu as une laison directe entre tes classes Model et View ce qui n'est pas normal.

Est ce que MVC n'est pas indiqué pour cette appli (ça serait étonnant mais pourquoi pas) ou peut être y a t-il un modèle plus approprié?

A mon avis un des seuls cas où le mvc est inapplicable c'est quand il n'y a pas d'ihm tout simplement.

D'aprés ton diagramme, je pense que tu n'as pas bien compris le but du controlleur. Il est juste sensé "piloter" ton modèle c'est à dire que tes classes vues passe par lui pour obtenir les services du modèle. Par exemple le contrôle de la souris n'a rien à faire au niveau du controlleur, il doit être dans la vue.
De plus le controlleur ne se limite pas forcément à une seule classe, tu devrais avoir une classe controlleur par couple acteur-cas identifié d'aprés tes diagrammes de cas d'utilisation.


Voilà j'espère que tu y vois un peu plus clair
ben

[TonioLeRital]

salut,

je vais essayer de t'éclairer un peu bien que je ne sois pas un expert du design pattern MVC


Non du tout, il sert simplement à changer "de vue comme de chemise" comme tu l'as dit


En tout cas il y a un gros problème dans ton diagramme, le mvc a pour but de séparer complètement le modèle de la vue. Or Tu as une laison directe entre tes classes Model et View ce qui n'est pas normal.


A mon avis un des seuls cas où le mvc est inapplicable c'est quand il n'y a pas d'ihm tout simplement.

D'aprés ton diagramme, je pense que tu n'as pas bien compris le but du controlleur. Il est juste sensé "piloter" ton modèle c'est à dire que tes classes vues passe par lui pour obtenir les services du modèle. Par exemple le contrôle de la souris n'a rien à faire au niveau du controlleur, il doit être dans la vue.
De plus le controlleur ne se limite pas forcément à une seule classe, tu devrais avoir une classe controlleur par couple acteur-cas identifié d'aprés tes diagrammes de cas d'utilisation.


Voilà j'espère que tu y vois un peu plus clair
ben

Bonjour,

j'aurais deux remarques à faire:

1) D'une part, il est vrai que le paradigme MVC à pour but de rendre les objets de la vue et du modèle mutuellement indépendants. Cependant en pratique, je pense qu'on gagne à ne pas casser la dépendance de la vue vers le modèle dans certains cas particuliers. Typiquement, le développement d'une interface de client riche peut à mon avis violer cette règle si les 3 couches MVC sont déployées sur la même machine et ne sont pas destinées à être distribué dans le futur. En effet, pour qu'une vue ne dépende plus de son modèle il faut passer par certains design pattern (ex. DTO) dont la mise en place peut s'avérer couteuse en terme de développement, bien que je la préconise fortement dans le cadre d' applications distribuées (le risque des DTO est de transformer votre application en jeu de piste). Dans le cas, d'une application déployée à 100% sur une machine cliente, dans la mesure où les objets du modèle sont passés à la vue par référence et non par valeur, on ne perd quasi rien en performance, et on gagne fortement en temps de développement, donc je pense qu'il n'y a pas de politique réellement efficace pour cette gestion de la dépendance entre les vues et leur modèle.

2) d'autre part, concernant le rôle du contrôleur, encore une fois je pense que les deux approches sont pratiquées et justes. Dans une approche orienté composant, on définit un seul et même objet qui est responsable de la vue et de la capture des évènements utilisateurs (objet "boundaries" de Jacobson) et personnellement je suis entierement favorable à cette approche (c'est d'ailleurs l'approche que j'utilise dans nos projets via l'utilisation de système RAD avec le framework des JSF). ensuite il y l'approche classique du MVC, où il me semble que en plus de la gestion du flux de l'application, un contrôleur a aussi la responsabilité de capturer les évènements utilisateurs, donc le schéma présenté ne me semble pas erroné sur ce plan.

bon courage à vous,
à bientot.

[tristan_m]

Bonjour,

D'abord merci beaucoup d'avoir décortiqué mon diagramme et pris le temps de m'apporter ces précisions!

Je m'aperçois que j'étais quand même très à l'ouest

En fait dans mon livre sur les design patterns (qui ne décrit malheureusement MVC que dans les grandes lignes), il est indiqué que la relation vue - controleur est un pattern strategie.
Dans mon esprit je pensais qu'une vue était une statégie d'affichage pour un controleur. Si j'ai bien compris vos messages, ce serait plutot le controleur qui implémenterait plusieurs stratégies (des sous classes en l'occurence) de réponse pour la vue?



En revanche je suis un peu perdu sur deux points:

1)Par qui sont gérées les modifications du modele?

• Est ce que le modèle définit lui même toutes les règles de modification, auquel cas le controleur ne serait qu'un traducteur des requètes pour la vue
• Est ce que le controleur gère la logique de fonctionnement de l'application, ne laissant au modèle "que" le role de base de données "statique"

2)Dans le cas où les évenements utilisateurs sont gérées par la vue (qui semble être le meilleur choix), où se situe la liaison avec la boucle principale du programme?
Typiquement pour un casse brique, lorsque l'utilisateur est inactif, la balle bouge quand même, il faut bien que l'un des blocs modele/vue/controleur indique cette incrémentation temporelle quelque part?

• Est ce que c'est considéré comme une action utilisateur (auquel cas gérée par la vue)?
• Est ce qu'il faut gérer ça par le controleur ou le modèle?
• Est ce que ces modifs sont toutes gérées par la boucle principale qui indique à chacun cette incrémentation?
• Est ce que je suis en Alaska avec mes propositions (c-a-d encore plus à l'ouest qu'avant )?

Bon ces questions se situent peut être un peu trop au niveau programmation et pas assez au niveau conception pour cette catégorie du forum, mais j'avoue que j'ai un peu de mal à bien comprendre la logique de MVC à un niveau plus abstrait

Merci encore pour vos réponses.

[benohite]

1)Par qui sont gérées les modifications du modele?

• Est ce que le modèle définit lui même toutes les règles de modification, auquel cas le controleur ne serait qu'un traducteur des requètes pour la vue
• Est ce que le controleur gère la logique de fonctionnement de l'application, ne laissant au modèle "que" le role de base de données "statique"

Le modèle définit effectivement lui-même les règles de modification, il n'empeche que tu peux les paramètrées. Ex: la vitesse de balle, saisie via la vue et transmise au modèle grace au controleur
Je ne suis pas sur d'avoir bien saisi le 2e point, mais pour moi le controleur ne gère pas la logique de fonctionnement, c'est le modèle qui offre les "services" et donc qui en assure le déroulement. Aprés si tu veux dire qu'il faut cliquer sur le bouton démarrer avant de pouvoir jouer par ex, la je dirais plutôt que c'est la vue. Le controleur ne servant que de passerelle entre vue et modèle.

2)Dans le cas où les évenements utilisateurs sont gérées par la vue (qui semble être le meilleur choix), où se situe la liaison avec la boucle principale du programme?
Typiquement pour un casse brique, lorsque l'utilisateur est inactif, la balle bouge quand même, il faut bien que l'un des blocs modele/vue/controleur indique cette incrémentation temporelle quelque part?

• Est ce que c'est considéré comme une action utilisateur (auquel cas gérée par la vue)?
• Est ce qu'il faut gérer ça par le controleur ou le modèle?
• Est ce que ces modifs sont toutes gérées par la boucle principale qui indique à chacun cette incrémentation?
• Est ce que je suis en Alaska avec mes propositions (c-a-d encore plus à l'ouest qu'avant )?

L'incrémentation comme tu le dis se trouve au niveau du modèle puisque c'est lui qui implémente le comportement de l'application. La vue peut demander (via le controleur) par exemple un démarrage ou un arrêt.
Selon moi l'incrémentation n'est pas considérée comme une action utilisateur, elle fait partie intégrante du modèle.
Pour implémenter cette incrémentation, le plus simple est d'utiliser un timer qui se reveillera à un intervalle de temps donné et tu n'auras plus qu'a redessiner le plateau de jeu. En principe ce timer est executé dans un thread distinct.

Je dirais pas que tu es aussi loin que l'Alaska, plutôt l'Angleterre (humour)....

[TonioLeRital]

En revanche je suis un peu perdu sur deux points:

1)Par qui sont gérées les modifications du modele?

• Est ce que le modèle définit lui même toutes les règles de modification, auquel cas le controleur ne serait qu'un traducteur des requètes pour la vue
• Est ce que le controleur gère la logique de fonctionnement de l'application, ne laissant au modèle "que" le role de base de données "statique"

Salut,

la logique de ton application doit être compris dans ton modèle. Par contre, le flux de l'application, cad les comportements de ton application suivant les actions de l'utilisateur sont gérés par le contrôleur, qui délèguera au bon service du modèle. Dans une modélisation objet, quand tu attribues les responsabilités à tes objets suivant GRASP, tu constates que le seul moyen de conserver un faible couplage et une haute cohésion dans un graphe objet, c'est dans ton cas, d'attribuer les comportement métier aux objets métier eux-même (cad les objets du modèle).

2)Dans le cas où les évenements utilisateurs sont gérées par la vue (qui semble être le meilleur choix), où se situe la liaison avec la boucle principale du programme?
Typiquement pour un casse brique, lorsque l'utilisateur est inactif, la balle bouge quand même, il faut bien que l'un des blocs modele/vue/controleur indique cette incrémentation temporelle quelque part?

• Est ce que c'est considéré comme une action utilisateur (auquel cas gérée par la vue)?
• Est ce qu'il faut gérer ça par le controleur ou le modèle?
• Est ce que ces modifs sont toutes gérées par la boucle principale qui indique à chacun cette incrémentation?
• Est ce que je suis en Alaska avec mes propositions (c-a-d encore plus à l'ouest qu'avant )?

Bon ces questions se situent peut être un peu trop au niveau programmation et pas assez au niveau conception pour cette catégorie du forum, mais j'avoue que j'ai un peu de mal à bien comprendre la logique de MVC à un niveau plus abstrait

Merci encore pour vos réponses.

Je suis du même avis que benohite: dans ce cas, c'est ton modèle qui doit gérer l'incrémentation par exemple par la mise en place d'un timer. Dans ce cas et typiquement il est judicieux d'implémenter le design pattern "observer/Observable", c'est un design pattern qui permet au modèle de notifier à toutes ses vues qu'il à changé (suite à un évènement qui ne parvient pas forcément du contrôleur , comme des évènement asynchrones par ex.) afin qu'elles se rafraichissent, sans pour autant que le modèle n'ai de dépendance envers ses vues (c'est magique!), c'est un pattern très puissant ou le polymorphisme objet prend tout son sens!

Sinon, Alaska ou pas, je trouve que tu poses les bonnes questions, les questions qu'on se pose quand on cherche à faire au mieux avec ce qu'on a, c'est à dire un (ou des) bouquins d'UML / UP d'un coté et un ordi avec une console de l'autre, bref la jonction entre la théorie et la pratique n'est pas évidente mais on y gagne beaucoup à la travailler.

bon courage.

[tristan_m]

Bonjour,

Encore une fois merci énormément d'aider le petit scarabée que je suis!

Je me suis un peu renseigné sur GRASP (je ne connaissais pas), et ça m'a permis de bien conforter ma compréhension des concepts que vous m'avez expliqué.
Notamment le pattern controller évidemment.
Au passage, au cours de mes recherches je suis tombé sur cette page :
http://fr.wikipedia.org/wiki/Anti-patron
qui décrit les anti pattern (fautes de conception dans un design pattern) et qui me semble assez intéressante pour ceux qui comme moi ont un petit manque d'expérience dans ce domaine (on va appeler ça comme ça )


Par contre je vais encore faire mon boulet sur des questions qui ne concernent plus trop MVC, ou au plus de façon indirecte...

Au sujet du timer, ça m'embête un peu qu'il soit dans le modèle, même si je comprends -maintenant- -Merci à vous- tout à fait le principe.
Ce qui me pose problème c'est que dans la plupart des jeux temps réel (c'est un peu pompeux pour un casse brique mais bon ), c'est l'affichage le goulot d'étranglement.
Donc le timer c'est plus la carte graphique, a fortiori gérée par la vue, qui indique une fois l'affichage terminé que les données peuvent/doivent être mises à jour.
C'est pourquoi le principe d'action utilisateur me plaisait bien, mais cette désignation cache peut être une dépendance du modèle vis-à-vis de la vue...

A l'heure actuelle, mon programme étant à thread unique et non distribué, il suffirait que je fasse ainsi (désolé j'ai encore un peu de mal avec les diagrammes de séquence...):

1 - Traitement des interactions (clavier, souris, messages de l'OS, etc...)
2 - Mise à jour des données par le modèle.
3 - Notification vers la vue.
4 - Acquisition des nouvelles données par la vue,
4 bis - Réaffichage du plateau de jeu.
5 - Retour en 1.

Dit comme ça, la vue n'aurait même rien à envoyer au controleur (à ce niveau là), donc apparemment pas de dépendance, mais j'ai l'impression que cela ne marche que grace au cas particulier thread unique/non distribué.

• Est ce qu'il s'agirait d'une erreur de conception?
• Est ce que les cas multithread et/ou distribué répondent à d'autres modèles de conception?

Pfiou j'ai fait long, j'espère que c'est clair au moins (c'est pas gagné)?



Autre question à propos du pattern observer.
Mon modèle possède beaucoup d'objets, mais dans 99% des cas, seule la balle est vraiment modifiée. Dans ma précédente implémentation, j'avais des relations sujet -> observateur entre toutes les entités quasiment (non représentées sur le diagramme) :
ball -> graphicBall
paddle -> graphicPaddle
etc...

• Est ce que c'est la bonne façon de faire (évitant les requêtes/mises à jour inutiles)?
• Est ce qu'il vaut mieux faire une seule notification via le modèle et de faire passer toutes les requêtes d'acquisition des nouvelles données via la vue (simplifiant l'architecture)?
• Est ce qu'il y a une toute autre façon de faire?

Désolé pour toutes ces questions (mes messages sont de plus en plus longs...) j'essaie de les présenter clairement à défaut de faire concis...

En tout cas mille mercis pour votre aide et vos encouragements!!!
D'ailleurs je pensais être beaucoup plus loin que l'Angleterre, genre perdu en plein milieu de l'Atlantique

Merci encore