Discussion :

[sourivore]

Bonjour,

J'ai une question que je me pose à chaque fois (ou presque) que je conçois une application.
Quelle est la stratégie de conception des controllers ?
Exemple concret pour un jeu de carte :
J'ai une classe Jeu et une classe Effet. Cette classe Effet correspond à une action sur le jeu (par exemple piocher une carte lancer un dé...) et la classe Jeu contient donc toutes les données de la partie, les cartes présentes par exemple.

Mon problème est donc le suivant :
Je me suis créé un JeuController qui connait le jeu courant.
Ce controller a plusieurs méthodes qui permettent d'initialiser le jeu, déterminer le nombre de cartes en jeu, etc...
Par contre j'hésite pour la façon dont implémenter la gestion des effets.
Soit :
- C'est le controller qui fait tout et a donc des méthodes comme piocherCarte, melangerPiocheJoueur, lancerDe... => Inconvénient énormément de méthodes
- On créé un effetController qui connait également le jeu courant et est spécialisé dans la gestion des effets de carte. Le JeuController devra donc par moment faire appel a EffetController => Inconvénient : Un controller qui appelle un autre controller
- Même chose sauf que EffetController ne connait pas le jeu et n'est pas accessible directement depuis la vue. Il faut donc obligatoirement passer par le JeuController => Inconvénient effetController est-il dans ce cas vraiment encore un controller plutot qu'une bibiliothèque utile ?

Merci d'avance, je tombe régulièrement sur ce genre de problème dès que j'ai beaucoup de méthodes à implémenter dans un controller ou que je me retrouve avec des controller qui sont assez sembables (ici JeuController et EffetController ont tous les deux des effets sur le jeu)

Merci d'avance

[wiztricks]

MVC ne devrait être utilisé que pour la réalisation de l'IHM graphique.

Je me suis créé un JeuController qui connait le jeu courant.
Ce controller a plusieurs méthodes qui permettent d'initialiser le jeu, déterminer le nombre de cartes en jeu, etc..

A la base vous devriez avoir un objet "Jeu" et des méthodes pour retourner le nombre de cartes, mélanger,...

- C'est le controller qui fait tout et a donc des méthodes comme piocherCarte, melangerPiocheJoueur, lancerDe... => Inconvénient énormément de méthodes

Certes, mais piocherCarte est d'abord une action qui retire la première carte de l'objet "jeu" pour l'ajouter à celles de la "main" du "joueur" courant. Une action du jeu pourra modifier l'état de plusieurs objets.

Suivant l'avancée de la partie, chaque joueur pourra/devra effectuer un certain nombre d'actions définies par les règles du jeu de cartes.
Ces actions modifiant l'état des objets du modèle seront associées à des méthodes des objets (du modèle).

Une fois le contour du "modèle" un peu plus "clair", on peut ajouter une interface mode console ou une interface graphique et, dans ce cas, que sont Views et Controllers?

On peut imaginer présenter dans une fenêtre de l'écran de chaque joueur:

• la pioche
• les différentes cartes de sa main,
• la table de jeu.

"piocherCarte" pourra être l'action déclenchée lorsque le joueur clique sur "la pioche". Cette action modifie l'état de l'objet "cartes de la main", la View correspondante reflétera cet état.

"jouercarte" pourra être l'action déclenchée lorsque le joueur "clique" sur une des cartes de sa main: changement de l'état des objets "cartes de la main", "table de jeu" et mise à jour des Views dans les fenêtre de chaque joueur.

=> les Views "montrent" une représentation de l'état des objets du modèle en temps réel si possible.

Un jeu de carte peut être représenté côté modèle par un objet identifié par un entier et une couleur. Côté View, sera montré une image de la carte correspondante mais çà ne doit rien changer côté Modèle: c'est à l'IHM de gérer la correspondance.

=> MVC dit seulement que l’interprétation de l'information clic sur le pavé de la fenêtre montrant les différentes cartes de sa main doit être faite par "Contrôleur".

A lui de récupérer l'objet du "modèle" représenté dans la View lorsqu'est activée la méthode "on_card_clicked" pour pouvoir appeler "jouerCarte(player, carte)" avec les bonnes informations.

En espérant que mes bavardages vous auront éclairé quelque peu.
- W

[tristan_m]

Bonjour,

Le rôle du contrôleur est effectivement le plus difficile à cerner.
En gros il y a le modèle qui contient les données, la vue qui les affiche, et le contrôleur qui est le "truc" au milieu .

Cependant la question est suffisamment précise pour trouver une réponse. Voici une page de SUN/Oracle à laquelle je me réfère souvent lorsque je me pose ce type de question :
http://java.sun.com/blueprints/patte...-detailed.html


On y voit que le contrôleur définit le comportement de l'application. wiztricks a très bien décrit cet aspect, je ne vais donc pas insister dessus.
L'autre information est qu'il y a un contrôleur par fonctionnalité.

Il faut donc réfléchir à ce que doit faire votre application en termes de fonctionnalités. Votre problématique, de mon point de vue, est donc uniquement de bien définir ces fonctionnalités.
Les lecteurs multimédia sont un exemple assez explicite d'applications proposant plusieurs fonctionnalités :

• La lecture (démarrage, pause, avance rapide, retour rapide, etc...) d'un fichier multimédia
• La gestion d'une liste de lecture
• La gestion d'une bibliothèque multimédia
• La gravure d'un CD
• etc...

Ces fonctionnalités sont indépendantes les unes des autres. On peut donc imaginer un contrôleur différent pour chacune.


Pour en revenir à votre cas, avoir un contrôleur 'Jeu' et un contrôleur 'Effet' signifie que l'application aurait deux fonctionnalités différentes 'Jeu' et 'Effet'. On se rend compte tout de suite du problème, puisque 'Effet' semble être un sous-ensemble de 'Jeu', ou au moins fortement intégrée.
Une fonctionnalité séparée serait, par exemple, une fonctionnalité 'mutijoueur' contenant un nombre de points lié aux différentes parties jouées, avec une liste de joueurs, un classement, etc... Cette fonctionnalité serait indépendante de la fonctionnalité 'Jeu' identifiée et serait donc sujette à un contrôleur dédié.

Donc dans votre exemple, il faut soit :

• Considérer avoir une fonctionnalité globale 'Jeu' (et donc un contrôleur unique 'JeuController'),
• Identifier des 'sous-fonctionnalités' différentes dans l'application (avec un contrôleur pour chacune de ces fonctionnalités).

NB : Ce n'est pas très clair dans votre message, mais j'ai l'impression qu'il y a une confusion entre décomposition en classes et 'décomposition en contrôleurs'. On peut très bien déléguer les traitements dans des classes séparées sans pour autant créer un contrôleur pour chacune de ces classes. Typiquement, la classe 'JeuController' peut avoir un membre 'effet' sans que 'effet' ne soit un contrôleur séparé.

Quelques remarques par rapport à votre message:

C'est le controller qui fait tout et a donc des méthodes comme piocherCarte, melangerPiocheJoueur, lancerDe... => Inconvénient énormément de méthodes

Le nombre de méthode est juste le reflet de la complexité de la fonctionnalité, pas de son implémentation. L'implémentation, si elle est bien conçue (décomposition en classes, etc...), peut/doit être un ensemble de fonctions très simples.

Même chose sauf que EffetController ne connait pas le jeu et n'est pas accessible directement depuis la vue. Il faut donc obligatoirement passer par le JeuController => Inconvénient effetController est-il dans ce cas vraiment encore un controller plutot qu'une bibiliothèque utile ?

Plutôt qu'une bibliothèque utile, je dirais plutôt que effetController, qui n'est effectivement plus un contrôleur, est une partie de JeuController qui est en charge d'un sous ensemble des méthodes de la fonctionnalité 'Jeu'. Je ne considèrerais pas ça comme un inconvénient, dans le sens où cela supprime un contrôleur qui était "en conflit" avec un autre.

Bon courage pour vos futures identifications