Projet Zuul de conception orientée objet en Java d'un jeu d'aventure
Forum des exercices du projet Zuul
Exercice 7.18.1
Abonné
Le projet zuul-better.jar [ci-joint] est un exemple de réalisation d'une partie des exercices qui vous ont été demandés jusqu'à présent.
Comparez-le à votre projet (surtout pour la gestion des sorties et des descriptions) ; vous pouvez aussi regarder la documentation de ce projet.
Ne transférez aucun code, corrigez le minimum nécessaire, sans aucune régression (notamment, ne pas perdre printLocationInfo dans Game et getCommandList dans Parser et dans CommandWords, conservez les boucles for each) .
Tout recompiler : il ne doit y avoir aucun warning.
Bonjour,
je ne comprends pas pourquoi on devrait remplacer le code de la méthode
processCommand par celui inclus dans zuul-better, en effet celui-çi
"impose'" un ordre des commandes à savoir d'abord help puis go puis quit
et si on ne respecte pas cet ordre, il affiche une erreur, alors
qu'avec l'ancien code présent dans ma version courante, toutes les
combinaisons sont possibles, merci d'avance!
> "je ne comprends pas pourquoi on devrait remplacer le code de la méthode processCommand par celui inclus dans zuul-better"
>
Où est-il écrit que vous devez remplacer le code de processCommand ?
On
vous fournit juste un exemple de projet pour pouvoir le comparer au
vôtre, et vous aider si vous n'êtes pas arrivé à résoudre un exercice
précédent.
> "celui-çi "impose'" un ordre des commandes à savoir d'abord help puis go
puis quit et si on ne respecte pas cet ordre, il affiche une erreur"
>
Je ne vois pas pourquoi le code qui vous est fourni impose un ordre quelconque.
Si vous modifiez l'ordre des if / else if, cela continuera de fonctionner de la même façon.
Je n'ai plus printLocationInfo dans Game, n'étais-t-il pas devenu obsolète sachant que nous avons look et getLongDescription dorénavant ?
Par quelles lignes de code avez-vous remplacé les appels à printLocationInfo ?
Lisez les 2 premiers messages sous l'énoncé de l'exercice 7.14.
La commande look n'est que le 3ème endroit où vous devez appeler printLocationInfo.
Il n'y a aucune raison de supprimer printLocationInfo qui était déjà utilisée à 2 endroits.
Un étudiant a écrit :
après avoir relu le projet zuul-better, je ne comprends pas l’intérêt
d’import StringTokenizer au début de la classe Parser étant donné qu’on
ne l’utilise pas.
Bien vu !
L'auteur de cette classe a dû écrire sa première version avec un StringTokenizer pour découper la String lue, puis il s'est ravisé et a décidé d'utiliser un Scanner une 2ème fois, ce qui permet de n'importer et n'expliquer qu'une seule classe du JDK (voir les 4 utilisations de Scanner dans un cours précédent).
Vous pouvez donc terminer son travail en supprimant cet import inutile.
Activer le mode édition
Paramètres
Utilisateurs inscrits
Groupes
Voir les permissions
Autres utilisateurs
Filtres
Rapport des compétences
Notes
Sauvegarde
Restauration
Importation
Réinitialiser
Compétences
Enseignant non éditeur
Réseaux sociaux