Forum des exercices du projet Zuul

Exercice 7.31.1

  
 
Avatar anonfirstname2 anonlastname2
Exercice 7.31.1
par anonfirstname2 anonlastname2, mardi 22 novembre 2016, 10:44
 

Créer une nouvelle classe ItemList pour gérer une liste d'items et ainsi mutualiser la gestion des items qui se retrouvait dupliquée dans Room et dans Player.
Cette modification du choix de stockage des items interne à Room et à Player ne devrait entraîner aucune modification de GameEngine.

Conseil : Pour le choix de la collection utilisée dans ItemList, se demander comment retrouver un Item à partir de son nom...

Contraintes :
- La collection d'objets utilisée dans ItemList n'est pas censée pouvoir être manipulée depuis l'extérieur d'ItemList.
- L'ItemList n'est pas censée pouvoir être manipulée depuis l'extérieur de Room ou de Player.

Ne pas oublier de lire les échanges ci-dessous pour mieux comprendre la bonne manière de réaliser cet exercice.


Aide :
Vous voulez savoir si vous avez correctement fait cet exercice ?
Dans ItemList, remplacez partout la collection que vous avez utilisée par TreeMap.
Si sans RIEN changer en dehors d'ItemList, tout compile normalement, c'est bon !
Sinon, on en parle ?


Avatar Victor OU
Re: Exercice 7.31.1
par Victor OU, samedi 2 novembre 2013, 12:11
 

Je ne comprends pas trop le but de cette exercice pourriez-vous donner un petit peu plus d'explications s'il vous plaît?

Lorsque vous parler de duplication faîtes-vous référence au fait que si notre joueur prend un objet, il reste toujours disponible dans la room associée?

Avatar Denis BUREAU
Re: Exercice 7.31.1
par Denis BUREAU, dimanche 3 novembre 2013, 19:40
 

Non, pas du tout :

1) Si le joueur prend un objet, cet objet ne doit plus se trouver dans la pièce où il était.

2) Comme indiqué dans l'énoncé, c'est la gestion des items qui est dupliquée, c'est-à-dire notamment la collection qui stocke les items et les méthodes pour ajouter, retirer, ...

Une fois que vous aurez écrit la classe ItemList, les classes Room et Player auront chacune un attribut du type ItemList et n'auront plus à connaître le type de la collection utilisée à l'intérieur d'ItemList et la manière de la manipuler.

Avatar Victor OU
Re: Exercice 7.31.1
par Victor OU, jeudi 28 novembre 2013, 21:18
 

Je viens de revenir sur l'utilisation de cette classe et je me posais une question.

Est-il mieux de de faire appel à l'objet ItemList dans les classes Room et Player puis d'utiliser les méthodes écrites dans la classe ItemList pour la modifier telle qu'une méthode addItem ou removeItem ou bien est-ce mieux de définir dans la classe Room et Player une méthode addItem faisant appel à la méthode précédemment définit dans la classe addItem?

Je pose cette question car cela implique dans le premier cas d'écrire une instruction un petit peu plus longue que dans le second cas. Et je ne sais pas s'il est préférable d'avoir une écriture compacte ou bien mieux détaillée.

Cordialement.

Avatar Denis BUREAU
Re: Exercice 7.31.1
par Denis BUREAU, vendredi 29 novembre 2013, 10:28
 

"Est-il mieux de de faire appel à l'objet ItemList dans les classes Room et Player puis d'utiliser les méthodes écrites dans la classe ItemList pour la modifier telle qu'une méthode addItem ou removeItem"

OUI

"Je pose cette question car cela implique dans le premier cas d'écrire une instruction un petit peu plus longue que dans le second cas. Et je ne sais pas s'il est préférable d'avoir une écriture compacte ou bien mieux détaillée."

L'écriture a peu d'importance. Ce qui compte, c'est que chaque classe ait un rôle bien défini, c'est de ne pas dupliquer de code, c'est de ne pas rendre inutilement accessible des attributs (surtout des collections) hors de leur classe, ...

Avatar Jonathan MORELL
Re: Exercice 7.31.1
par Jonathan MORELL, mardi 29 avril 2014, 00:00
 

Si je comprends bien, le but de cette exercice est de remplacer nos HashMap d'items présent dans Room et Player par un objet de la classe ItemList ?

Avatar Denis BUREAU
Re: Exercice 7.31.1
par Denis BUREAU, mardi 29 avril 2014, 09:44
 

tout à fait, mais surtout pour ne pas dupliquer les méthodes de gestion de ces HashMap

Avatar Louis TRAMECON
Re: Exercice 7.31.1
par Louis TRAMECON, lundi 15 décembre 2014, 20:11
 

Mais je ne comprend pas, cette classe n'a pas de sens, car elle est contradictoire avec la classe player, vue qu'il y a autant de joueur que d'inventaire du coup si j'ai bien compris le but de l'exercice on ferait une régression.

De plus, si on suis la logique, on devrait aussi avoir une classe qui liste les Rooms, hors se n'est pas le cas, les salles sont instancier dans gameEngine et géré par la classe Room, au même titre que les objets avec la classe Items alors pourquoi ferions nous une différence entre les deux

Avatar Denis BUREAU
Re: Exercice 7.31.1
par Denis BUREAU, mardi 16 décembre 2014, 10:23
 

> Mais je ne comprend pas, cette classe n'a pas de sens,
Je pense que vos mots ont dépassé votre pensée ...

> car elle est contradictoire avec la classe player, vue qu'il y a autant de joueur que d'inventaire du coup si j'ai bien compris le but de l'exercice on ferait une régression.
Cette classe n'a rien de contradictoire avec ce qui a été fait précédemment, elle est une amélioration : au lieu d'effectuer la gestion des Items deux fois (dans Room et dans Player), on ne l'écrit plus qu'une seule fois dans ItemList et on s'en sert dans Room et dans Player. Autre avantage : si l'on décide de changer de collection pour stocker les Items, cela ne se verra pas à l'extérieur d'ItemList, et aucune modification ne devra être effectuée sur aucune autre classe.

> De plus, si on suis la logique, on devrait aussi avoir une classe qui liste les Rooms, hors se n'est pas le cas, les salles sont instancier dans gameEngine et géré par la classe Room, au même titre que les objets avec la classe Items alors pourquoi ferions nous une différence entre les deux
Ce n'est pas le même problème puisque nous n'avons pas, après le début du jeu, à "gérer" (ajouter, supprimer, lister, ...) les Rooms, alors que nous devons le faire (dans Room et dans Player) pour les Items.
Mais pour d'autres raisons, il est tout à fait possible de mettre en place une collection de Rooms, bien que ce ne soit pas demandé.
Avatar Louis TRAMECON
Re: Exercice 7.31.1
par Louis TRAMECON, mardi 16 décembre 2014, 12:53
 

Donc concrètement, on nous demande d'importer les deux HasMap (une dans Player et une dans Room) qui concerne les items à l'intérieur d'une même classe ItemListe ?

Avatar Denis BUREAU
Re: Exercice 7.31.1
par Denis BUREAU, mardi 16 décembre 2014, 13:40
 

Pas du tout !

On vous demande de remplacer dans Room et dans Player votre collection d'Items par une ItemList, cette classe étant chargée de gérer une collection d'Items.


Avatar Mathieu CARANGEOT
Re: Exercice 7.31.1
par Mathieu CARANGEOT, lundi 8 mai 2017, 20:24
 
Bonjour,

J'ai une erreur: java.lang.NullPointerException: null dans ma méthode qui permet de d'initialiser les items de mon jeu (cette méthode est dans la classe Room)

        /**
         * Fixe les items présents dans les pièces.
         * @param pCle String La clé de l'item.
         * @param pItem Item L'item en question.
         */
        ... code supprimé pour ne pas influencer les futurs lecteurs ...


Cette méthode fait appel à addItem de la classe ItemList:

        /**
         * Ajoute un item à la HashMap.
         * @param String pString La clé associée à l'item que l'on ajoute.
         * @param Item pItem L'item que l'on veut ajouter.
         */
        ... code supprimé pour ne pas influencer les futurs lecteurs ...


De plus, j'initialise mes items dans createRoom de GameEngine de cette façon : vSuite.addRoomItem("clé",vCle);

Je ne comprends pas d'où vient cette erreur. Elle n'apparait pas à la compilation mais lorsque je lance mon jeu...


Avatar Denis BUREAU
Re: Exercice 7.31.1
par Denis BUREAU, mardi 12 mai 2015, 19:52
 

1) Vous avez l'air surpris que cette erreur survienne non pas à la compilation mais à l'exécution : c'est le propre de toute exception. Avez-vous compris le TP que vous avez eu hier ou aujourd'hui ?
D'une façon générale, une NullPointerException indique que vous avez appelé une méthode sur une référence valant null (qui ne pointe donc sur aucun objet !). Il suffit donc de remonter pour trouver où cette référence était censée être initialisée avec un objet pour trouver la cause du problème.

2) Vous ne me dites pas exactement à quelle ligne se produit la NullPointerException, mais je vais supposer qu'il s'agit de :
this.aRoomItems.addItem(pCle, pItem);
Je ne comprends pas ce qu'est aRoomItems et à quoi ça sert par rapport à aItemList ...

Avatar Charlotte COLBOIS RICHARD
Re: Exercice 7.31.1
par Charlotte COLBOIS RICHARD, lundi 11 avril 2016, 19:40
 

Bonjour, 


J'ai crée une classe ItemList et dans celle-ci une méthode getItem() qui me permet d'accéder à l'item de ma liste d'item.

Or, quand dans la classe GameEngine, dans la méthode take(), je fais appel à cette méthode getItem(), on me dit que cette méthode est introuvable.

ce que je ne comprends pas, car c'est souvent que l'on appelle une méthode publique d'une autre classe dans une classe. 

Pourriez-vous m'éclairer ? 

Merci. 


Avatar Denis BUREAU
Re: Exercice 7.31.1
par Denis BUREAU, mardi 12 avril 2016, 09:38
 

Pour vous aider précisément, il aurait fallu me donner l'instruction que vous avez écrite et qui provoque l'erreur !

Une hypothèse est que vous avez appelé getItem sur un objet qui n'est pas une ItemList ...

Avatar Jimmy HABIB
Re: Exercice 7.31.1
par Jimmy HABIB, mardi 10 mai 2016, 14:02
 

Bonjour, j'ai un problème avec ma méthode take depuis le changement due à ItemList:

Ma méthode à été modifiée en conséquence mais le problème j'ai l'erreur NullPointer sur un objet non-nul.


Exception in thread "AWT-EventQueue-1" java.lang.NullPointerException

at Player.take(Player.java:130) ->  if (aItemList.getItem(pItem.getaName()) != null)

Avatar Denis BUREAU
Re: Exercice 7.31.1
par Denis BUREAU, mardi 10 mai 2016, 18:42
 

Dans votre cas, il n'y a que deux possibilités : soit aItemList vaut null, soit pItem vaut null.

Vous conviendrez qu'il est très facile d'afficher ces 2 valeurs pour voir laquelle vaut null.

Ensuite, il vous restera à trouver ce qu'il faut corriger pour rendre cette valeur non nulle.

Avatar Denis BUREAU
Re: Exercice 7.31.1
par Denis BUREAU, dimanche 1 avril 2018, 23:04
 

Un étudiant a écrit :

J’ai traité cet exercice et mon code fonctionne correctement mais je me demandais s’il l’on doit afficher la nouvelle liste des objets présents dans la pièce à chaque fois que l’on prend ou dépose un objet ?

Avatar Denis BUREAU
Re: Exercice 7.31.1
par Denis BUREAU, dimanche 1 avril 2018, 23:04
 

Ce n'est pas explicitement demandé, mais vous pouvez le faire si vous voulez.

Avatar Denis BUREAU
Re: Exercice 7.31.1
par Denis BUREAU, mardi 3 avril 2018, 10:49
 

Un étudiant a écrit :

J'ai un problème lorsque je dois créer la classe ItemList.
En effet, dans ma classe Room, les items sont sauvegardés dans une hahsMap et dans player ils sont sauvegardés dans une ArrayList.
Il me semble donc impossible de créer cette classe...
Est-ce donc absolument nécessaire de créer cette classe?
Dans ce cas, suis-je obligé de mettre une hashMap dans player à la place de ma ArrayList ?

Avatar Denis BUREAU
Re: Exercice 7.31.1
par Denis BUREAU, mardi 3 avril 2018, 11:01
 

1) Pourquoi avoir choisi une ArrayList dans Player alors que la HashMap semblait donner satisfaction dans Room ?

2) Un conseil vous était donné dans l'énoncé : avez-vous remarqué qu'il était plus difficile de retrouver un item d'après son nom dans une ArrayList plutôt que dans une HashMap ?

3) Cet exercice est effectivement obligatoire et vous conduira à ne plus avoir ni ArrayList ni HashMap que ce soit dans Room ou dans Player : ils auront une ItemList !

4) L'intérieur de l'ItemList doit évidemment rester "caché", donc vous pourriez passer d'une ArrayList à une HashMap ou vice-versa sans aucune conséquence à l'extérieur de la classe ItemList.

Avatar Denis BUREAU
Re: Exercice 7.31.1
par Denis BUREAU, jeudi 26 novembre 2020, 10:46
 

Un étudiant a écrit :

Dans ma classe ItemList, que j'ai appelé Inventory car je trouve ce nom plus parlant (je ne sais pas si ça pose problème pour vous),
j'ai un attribut HashMap pour le stockage, un attribut PrixTotal, un autre PoidTotal et un PoidMax.
Ma question c'est pourquoi mettre  l'attribut PoidMax dans Player ?
J'ai fait une procédure booléenne addItem() dans Inventory qui vérifie que le poid total ne dépassera pas le poid maximal pouvant être supporté par l'inventaire. Je ne vois pas pourquoi le joueur devrait s'occuper de ça. 

Avatar Denis BUREAU
Re: Exercice 7.31.1
par Denis BUREAU, jeudi 26 novembre 2020, 11:00
 
  1. La raison pour laquelle on a appelé cette classe ItemList et non Inventaire est qu'elle ne sert pas que pour l'inventaire du joueur.
    La raison pour laquelle il ne faut pas modifier son nom, est que certains tests automatiques seront lancés sur votre programme, et vous pourriez être pénalisé s'ils ne trouvent pas la classe ItemList.

  2. Les attributs HashMap, PrixTotal (facultatif), et PoidsTotal semblent logiques dans une ItemList puisqu'ils représentent l'état de cette liste d'items ; par contre, le PoidsMax n'a rien à y faire puisqu'il dépend de chaque Player.
    La gestion des items est indépendante du Player ; la "force" du Player est indépendante de la gestion des items.
Avatar Denis BUREAU
Re: Exercice 7.31.1
par Denis BUREAU, vendredi 4 décembre 2020, 23:36
 

Un étudiant a écrit :

Dans l'énoncé, vous précisez que la classe GameEngine ne doit subir aucune modification. 
Or, comme j'ai déplacé la méthode permettant de créer un nouvel item dans la classe ItemList, je ne peux plus y accéder dans GameEngine (à moins de réaliser un accesseur, ce qui reviendrait à ignorer l'énoncé demandant de ne pas modifier GameEngine).
Pouvez vous m'aider ?

Avatar Denis BUREAU
Re: Exercice 7.31.1
par Denis BUREAU, vendredi 4 décembre 2020, 23:43
 

Vous avez bien fait de demander, car vous n'avez pas compris où intervenait ItemList.

En partant de la version du 7.30, il vous suffit de remplacer le stockage des items dans Room et dans Player, en passant de HashMap à ItemList.

Toutes les méthodes touchant aux items dans Room et dans Player devront donc être modifiées, mais on ne voit pas pourquoi il faudrait changer quoi que ce soit dans GameEngine ...

Avatar Denis BUREAU
Re: Exercice 7.31.1
par Denis BUREAU, dimanche 6 décembre 2020, 20:17
 

Un étudiant a écrit :

J'aurais une question par rapport à l'exo 7.31.1 qui est de créer une nouvelle classe ItemList. D'après ce que j'ai compris (avec l'aide du forum ), le but de cette classe nous permettra d'éviter d'écrire 2 fois "private HashMap<String,Item> aItems;" (dans les classe player et room).
Mais des méthodes tel que addItem ou removeItem (qui se trouvent dans ma classe Room et qui me permettent d'ajouter ou supprimer des item de la pièce) ou take, drop doivent - ils rester dans la classe Room ou dois-je les mettre dans la classe ItemList ?


Avatar Denis BUREAU
Re: Exercice 7.31.1
par Denis BUREAU, dimanche 6 décembre 2020, 20:23
 

Remplacer les 2 attributs HashMap par 2 attributs ItemList n'est pas le but, mais le moyen de rendre la gestion des items dans Room et Player indépendante du choix de la collection (par exemple HashMap ou ArrayList).

Room et Player auront toujours exactement les mêmes méthodes, mais celles-ci nécessiteront une adaptation de leurs instructions pour utiliser les services d'ItemList au lieu de ceux d'une HashMap.

Il faudra donc prévoir les services nécessaires dans la classe ItemList pour ne pas avoir à manipuler la collection depuis l'extérieur de cette classe.