Projet Zuul: Exercice 7.19.1 (OPTIONNEL)

Forum des exercices du projet Zuul

Exercice 7.19.1 (OPTIONNEL)

Vous n'êtes pas abonné à cette discussion. Cliquez pour vous abonner.

Après avoir fait l'exercice 7.19, étudier la documentation du projet zuul-mvc (Game, GameModel, TextView) et le fichier zuul-mvc.jar [ci-joint] pour comprendre son fonctionnement, et intégrer dans la version zuul-with-images que l'on vient de créer cette nouvelle conception plus proche de l'architecture MVC qui permettra par exemple de faire cohabiter 2 observateurs (texte + graphique).

zuul-mvc.jar

Permalien | Modifier | Supprimer | Répondre

Bonjour,

Je ne comprends pas bien la dernière phrase sur les "2 obervateurs", doit-on créer obligatoirement une classe TextView ou pouvons nous utiliser la classe UserInterface pour afficher les information (la vue)?

Merci de votre réponse.

Je viens de noter une différence comparé au projet zuul with images.

En effet, dans le projet zuul with images, la méthode play avait été supprimée or dans cette version zuul-mvc, je remarque qu'elle est de nouveau réintégré.

La méthode play doit-elle toujours restée présente ou bien il est autorisé de faire comme dans le projet zuul with images?

Cordialement.

Etant donné que cet exercice est optionnel, il ne peut rendre une modification obligatoire.

Même s'il était obligatoire, zuul-mvc est destiné à illustrer le modèle MVC, et il n'impose pas de revenir sur toutes les modifications faites dans les exercices précédents.

Très bien merci.

Un étudiant a écrit :

Bonjour,

Nous avons implémenté la structure MVC dans notre projet mais nous nous posons maintenant quelques questions.

Premièrement, avons-nous adopté la bonne structure ?   En effet, nous avons trouvé deux grandes déclinaisons de ce modèle : triangulaire, dans
lequel les trois parties communiquent entre-elles, et plat dans lequel le contrôleur joue le rôle d'intermédiaire pour toutes les actions. Nous
ne savons pas vraiment lequel convient le mieux au projet.

Deuxièmement, nous avons des problèmes pour déplacer certains attributs de la classe Game à la classe Player, tels que currentRoom, étant donné
que la liste des Room-s se situe dans la première classe. De plus, ayant utilisé une HashMap<String> pour stocker les Room-s, nous hésitons à
utiliser des String pour les sorties des pièces, sachant que cela pourrait éventuellement faciliter la future sauvegarde de l'état du jeu.

Cordialement,

Félicitations pour avoir implémenté le MVC dans votre projet !

A. Jean-Michel Douin a écrit : "plat, dans lequel le contrôleur joue le rôle d'intermédiaire pour toutes les actions" est inclus dans "triangulaire, dans
lequel les trois parties communiquent entre-elles". En général , la vue et le contrôleur sont liés (par exemple, addActionListener sur un bouton) ;
voir ici : http://lkubaski.wordpress.com/2012/12/20/java-se-application-design-with-mvc-with-images/

B. Pierre Lefebvre a écrit : Le modèle plat est celui que j'utilise et que je préconise dans mes cours JEE. Maintenant, comme le souligne Jean-Michel, il est inclus dans le modèle triangulaire, peut-être plus proche d'une vision MVC idéale. L'approche MVC telle que celle de Swing est d'ailleurs parfois critiquée dans certains articles comme celui-ci : http://www.brising.com/MVC.html

C. Je concluerais en disant qu'il est très difficile d'implémenter le "vrai" modèle MVC en Java, mais qu'une version approximative apporte déjà un surcroît de structuration et d'indépendance des différentes parties d'un logiciel.

A. Il n'y a (a priori) pas de problème pour déplacer aCurrentRoom de Game vers Player ; il suffit de prévoir un modificateur.

B. Vous parlez d'une HashMap<String> : il manque un type, avant ou après String. Vous parlez de stocker les rooms : s'agit-il de l'exercice optionnel 7.18.5 ? Vous parlez de String pour les sorties des pièces : s'agit-il de la HasMap des sorties dans les 4 directions ?

C. La future sauvegarde du jeu ne sera pas plus facile ou difficile en fonction du type que vous choisissez pour représenter les objets que vous avez à représenter ; en tout état de cause, ce choix doit être fait selon ce qui est le plus logique ou ce qui modélise le mieux la réalité, et non en fonction d'un hypothétique avantage concernant la sauvegarde.

1)

Merci pour cette clarification.
Nous avons maintenant adopté le modèle Model-Coordinator-View évoqué dans les articles, qui semble le plus apte à minimiser le couplage.
Nous essayons aussi de ne pas utiliser les ActionEvent de Swing en dehors de la vue associée, pour minimiser les modifications tout en gardant la compatibilité avec d'autres vues (console textuelle).

2)

A. Le problème venait du fait que notre classe Game comportait une méthode setCurrentRoom(String pRoomName) qui copiait la référence depuis la HashMap de l'exercice optionnel 7.18.5 vers l'attribut aCurrentRoom. Suite au changement de modèle, nous avons revu l'organisation et résolu en même temps ce problème.

B-C. Il s'agit effectivement de la HashMap<String, Room> des sorties que nous pensons substituer par HashMap<String, String>. En effet, lors de la sérialisation vers JSON pour la sauvegarde, nous nous retrouvons actuellement avec des références mémoires pour les Room de sortie. Or, ces références changent d'une exécution à une autre. Les remplacer par leurs nom nous semble alors une solution possible.

2BC :

Il ne me semble pas raisonnable de modifier aussi radicalement la structure du programme juste pour faciliter la sauvegarde.

Vous pouvez conservez la structure actuelle et récupérer le nom de la pièce au moment de la sauvegarde (à condition que ce soit un mot unique, pour permettre une re-création correcte lors de la restauration).

Revenir à Généralités

Projet Zuul de conception orientée objet en Java d'un jeu d'aventure

Forum des exercices du projet Zuul

Exercice 7.19.1 (OPTIONNEL)

Navigation

Administration

Navigation

Administration