Jouons à la guerre !

• UN seul zip pour l'nsemble des sources + photo UML + readme au format MarkDown + ...
• nommage du zip: NOM_PRENOM-td3b.zip

Exercice 1 - Questions

1. Retour sur l'héritage: On veut modéliser des soldats. Il existe cinq types de soldats : les soldats d'infanterie, de marine, les aviateurs, les médecins militaires et les spécialistes "lanceurs de flamme".
   Les soldats ont trois caractéristiques : la vitesse, la puissance de feu et les points de vie.
   La vitesse et la puissance de feu dépendent uniquement du type de soldats; les points de vie sont spécifiques à chaque soldat, mais les points de vie de départ sont spécifiques au type de soldat.
   Expliquez pourquoi ce n'est pas une bonne idée de faire de l'héritage pour ce problème ?
2. Imaginez un problème pour lequel le pattern Flyweight serait une bonne idée. Décrivez le en une phrase ou deux et justifiez l'intérêt du Flyweight dans ce contexte.
3. Donnez un exemple de pattern Composite que vous avez déjà rencontré ou codé. Etait-ce un composite transparent ou sûr ?

Exercice 2 - Des unités militairese

Le but de cet exercice est de modéliser des unités militaires, des soldats, des camions, etc.
Un soldat possède un type de base parmis 5 types prédéfinies (les soldats d'infanterie, de marine, les aviateurs, les médecins militaires et les spécialistes "lanceurs de flamme"). Sa vitesse et sa puissance de feu et ses points de vies au démarrage sont celle de son type de base.
On arrive donc au code suivant :

1. Ecrire un ou plusieurs tests unitaires JUnit creéant 4 soldats, un Medic, un InfantryMan, un Aviator et un FlameThrower et vérifiant que:
   • la somme de leur vitesse est 10.
   • la somme de leur point de vie est 70.
   • la somme de leur puissance de feu est bien 80.
2. On souhaite introduire une classe représentant un camion (ArmyTruck) dans lequel des soldats peuvent prendre place. La vitesse d'un camion est 10 et la puissance de feu est 20. Les points de vie d'un camion est la somme des points de vie de l'ensemble des soldats qui sont dans le camion.
   Ecrire la classe ArmyTruck et écrire un test unitaire correspondant.
3. On souhaite pouvoir représenter une liste d'unité militaire qui sont soit des soldats soit des camions. Comment faut'il faire ?
   Faite les modifications au niveau du code et ecrivez un test unitaires qui crée une liste d'unité militaire contenant un Medic, un InfantryMan et un camion contenant lui-même un Aviator et un FlameThrower puis vérifier que les sommes des vitesses, puissance de feu et points de vie sont exactes.
4. Expliquer en quoi la classe ArmyTruck n'est pas une realisation du design pattern composite.
   Est-ce grâve docteur ?
5. En fait, il existe bien un seul camion de l'armée mais chaque arme (air, terre et mer) à subtilement transformée sont camion ce qui fait que par exemple un marin qui appartient à l'armée de mer à bien du mal à utiliser son fusil sur un camion configuré pour l'armée de terre.
   En terme de modélisation, la puissance de feu d'un camion correspond à la somme des puissances de feux des soldats de la même arme que le camion. Les soldats des autres armées étant incapables de tirer correctement.
   Faites un diagramme UML (et prenez le en photo) du diagramme des classes qui prend un compte cette modification.
   Puis, effectuer les modifications correspondantes dans votre code.
   Note: Les médecins n'appartiennent à aucune armée particulière.
6. Pour aller plus loin ...
   Modifier votre code pour introduire un aircraft carrier et un destroyer qui peuvent aussi contenir des soldats avec les deux restrictions suivantes:
   • Un aircraft carrier (resp le destroyer) appartient uniquement à l'armée de l'air (resp l'armée de mer).
   • Il est possible de mettre un camion sur un aircraft carrier ou un destroyer mais pas l'inverse :)
     Cette condition doit être vérifiée à la compilation, et non pas à l'exécution !
   Attention, il ne *doit* pas y avoir de duplication de code entre un camion, un aircraft carrier et un destroyer.