:: Enseignements :: ESIPE :: E4INFO :: 2018-2019 :: Programmation Orientée Objet - Design Patterns ::
[LOGO]

Equilibrium

Mes premières factories
Equilibrium est un jeu à deux joueurs qui nécessite un papier et un crayon. Au début du jeu, le but est de tuer le joueur adverse (au sens figuré) en lui infligeant des dégats à chaque tour de jeu. Chaque joueur écrit une suite d'actions (une par ligne) sur un papier, ce que l'on appelle un deck. Chaque action est choisie parmi
  • Monster
    Monstre qui tape le joueur adverse et lui infige des dégats (de 1 à 3).
  • Ligthning
    Un éclair qui infige 2 ou 4 points de dégat à l'adversaire et inflige en même temps 1 ou 2 (respectivement) point de dégat au joueur ayant lancé l'action.
  • Cure
    Qui permet de guérir complètement le joueur. Celui-ci retrouve alors l'ensemble des ses points de vie.
  • Armor
    Le joueur revet une armure (à 1 ou 2 points) qui lui permet d'absorber une partie des dégats générés par les actions suivantes.
Une fois les decks constitués, on regarde s'ils sont équilibrés; on dit que l'on cherche l'équilibrium. Deux decks sont équilibrés s'ils ont le même nombre d'actions et si pour chaque catégorie d'action la somme des points est identique.
Par exemple, si Alice a le deck 
    monster 3
    monster 2
    monster 1
et Bob le deck 
    monster 2
    monster 2
    monster 2
alors les deux decks sont équilibrés car la somme des points de dégats est identique.
Voici un autre exemple d'équilibrium, pour Alice, le deck est 
 
    monster 3
    cure
    lightning 4
    monster 2
    monster 1
et pour Bob, le deck est 
    monster 2
    lightning 4
    monster 2
    cure
    monster 2

Exercice 1 - Equilibrium

Un chef de projet a demandé à un apprenti de programmer la résolution du jeu equilibrium, malheureusement, celui-ci n'a pas fini, seul les monstres sont gérés et de plus, il n'a pas suivi de cours de design pattern :(



  1. Quelles sont les 3 gros problèmes du code ci-dessus ?
  2. Dans un premier temps, on souhaite séparer le code de parsing de fichier de la création de Player, Expliquer pourquoi ? Quel design pattern allons nous utiliser ?
    Faire les changements.
  3. On souhaite fermer le code du parsing qui lit le fichier ligne à ligne. Que veux dire fermer un code ? Quel est l'intérêt de fermer un code ?
    Créer un package fr.umlv.parsing, sorter le code du parsing de fichier et fermer le. Puis modifier le code pour utiliser le parseur.
  4. Changer les problèmes restants.
  5. Vérifier que vous ne cassez pas l'encapsulation car un Iterator est mutable !
  6. On souhaite ajouter la gestion des éclairs (lightning). Comment doit on procéder ? Faire un diagramme UML du code à produire.
    Implanter votre diagramme UML sachant que
    • on peut remarquer que chaque action est définie par une seule méthode.
    • le code qui choisira si une ligne du fichier définie un monstre ou un éclair peut utiliser pour l'instant un switch.
  7. On souhaite refactorer le code qui fait un switch sur le type d'action pour ne pas coder en dur tous les types possibles d'action et ainsi permettre à n'importe quel code de définir ses propres actions.
    Dans un premier temps, créer une interface ActionFactory qui va permettre d'abstraire le code de création des actions et déplacer l'implantation du code dans le main de la classe Game.
    Bref implanter le design pattern factory object
    Attention la page wikipedia Factory method pattern est très mauvaise car elle confond factory method et factory object.
  8. On voudrait rendre le code un peu plus flexible et supprimer le switch en proposant une implantation de ActionFactory qui permette d'associer à un nom d'action le code permettant de créer une action.
    Il y a de la Map là-dedans ?
  9. Si vous ne l'avez pas encore fait, assurez-vous de pouvoir ajouter dynamiquement la possibilité de créer d'autres types d'Action.
  10. Ajouter les actions cure et armor
  11. Ajouter les tests vérifiant que
    • l'argument de monster est entre 1 et 3
    • l'argument de ligthning est entre 2 et 4 et pair.
    • l'argument de armor est entre 1 et 2
    sans dupliquer de code SVP.
  12. Votre main commence à être trop gros ?
    Déplacez dans ActionHelper les méthodes getDefaultMonsterFactory et getDefaultLighningFactory.
  13. Allons plus loin !
    On souhaite ajouter la verification de l'équilibrium avant le démarrage du jeux. Faites en sorte que la façon de vérifier soit définie par chaque type d'action et donc qu'il soit toujours possible d'ajouter des actions dans le main
© Université de Marne-la-Vallée