:: Enseignements :: Master :: M1 :: 2015-2016 :: Programmation Orientée Objet - Design Patterns ::

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 :(

Quelles sont les 3 gros problèmes du code ci-dessus ?
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.
On souhaite fermer le code du parsing de fichier qui produit un résultat ligne à ligne et renvoie une liste d'objet. 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 de Player pour utiliser le parseur.
Changer les problèmes restants.
Vérifier que vous ne cassé pas l'encapsulation car un Iterator est mutable !
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.
On souhaite refactorer le code qui fait un switch sur le type d'action pour ne pas coder en dure 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 pattern est très mauvaise car elle confond factory method et factory object.
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 en suivant le design-pattern AbstractFactory.
Ajouter les actions cure et armor
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.
Optionel
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