Examen 4h sur machine

Dans ce sujet, nous allons modéliser une entreprise qui fait des combats de robots virtuels.

Le sujet est composé comme suit :

• Dans l'exercice 1, nous allons nous intéresser à la modélisation des robots.
• Dans l'exercice 2, nous allons nous intéresser à la modélisation des arènes de combat virtuelles.
• Dans l'exercice 3, nous allons nous intéresser à un langage permettant de décrire les combats de robots.

D'un point de vue fonctionnel, le code demandé est très simple. Vous allez être évalué sur vos choix dans l'architecture du code : organisation des classes, choix des visibilités pour les champs et les méthodes, absence de duplication de code, respect des principes SOLID, choix des design-patterns...

RobotScripting

Toutes les classes de cet exercice doivent être dans le package fr.uge.poo.ex3.

Dans cet exercice et dans tous les autres, l'utilisation des switch de Java 17 est interdite.

Dans cet exercice, vous allez réaliser une librairie qui permet de traiter des fichiers qui décrive les évènements d'un combat de robots.

Ces fichiers seront au format suivant :

• TARGET$robot1$robot2 où robot1 et robot2 sont les noms des robots;
• DIES$robot$effect où robot est le nom du robot et effect est l'effet produit par la mort parmi EXPLOSION, SMOKE et NOTHING;
• DAMAGE$robot$amount où robot est le nom du robot qui subit les dégat et amount est la quantité de dégats reçue par ce robot;
• STARTROUND qui indique qu'un nouveau round vient de démarrer.

Par exemple, un fichier possible est:

STARTROUND
TARGET$alice$bob
DAMAGE$bob$12
DAMAGE$alice$1
TARGET$alice$charlie
DAMAGE$charlie$1000
STARTROUND
DIES$charlie$EXPLOSION

Ces fichiers peuvent décrire des combats qui ne respecte pas les règles des combats décrits à l'exercice précédent

Pour lire les lignes d'un fichier, vous pouvez utiliser:

  Path path = Paths.of("test.txt");
  var lines = Files.lines(path);

On vous demande d'écrire une librairie qui effectue le parsing de ces fichiers : c'est à dire qui passe d'un fichier textes à une liste d'objets Java.

Dans le package fr.uge.poo.ex3.rscript, écrivez une librairie permettant de parser des fichiers aux formats décrit précédemment. Cette librairie devra être utilisable par d'autres programmes pour traiter de fichier de scripts.

Dans le package fr.uge.poo.ex3, écrivez une application View qui prend en argument le chemin d'un fichier de scripts et des noms de robots et qui affichent pour chacun des robots la somme de ces dégats qu'il a subit pendant sur toutes actions ainsi que le nombre de rounds qu'a duré le combat décrit par le fichier.

Robot

Toutes vos classes pour cet exercice doivent être dans le package fr.uge.poo.ex1.

Dans cette exercice et dans tous les autres, l'utilisation des switch de Java 17 est interdite.

Pour le site MasterRobot, les robots ont les caractérisitiques suivantes:

• un nom, un poids (nombre entier) en grammes, une valeur d'attaque (ATT) entre 0 et 100, une valeur de défense (DEF) entre 0 et 100, une vitesse (SPD) entre 0 et 100, une liste des noms des compagnies qui sponsorisent ce robot. Ces informations ne peuvent pas être modifiée après la création du robot.
• le robot a aussi une barre de points de vie entre 0 et 100 qui commencera à 100. Elle évoluera au cours de la vie du robot.

Pour qu'une robot acceptable, il faut qu'il respecte un certain nombre de règles à la création:

• la somme de ATT, DEF et SPD ne doit pas dépasser 100 si le robot le robot pèse moins de 1000g et ne doit pas dépasser 200 sinon.
• un robot de plus de 1000g doit avoir au moins un sponsor.

Fonctionnellement, un robot doit avoir les méthodes suivantes:

• name qui renvoie le nom du robot;
• weight qui renvoie son poids;
• attack qui renvoie son niveau d'attaque;
• defense qui renvoie son niveau de défense;
• speed qui renvoie sa vitesse;
• life qui renvoie le niveau de vie du robot;
• chooseTarget(List<Robot>) qui renvoie Optional<Robot> correspondant au robot dans la liste qu'il préfère attaquer. Pour l'instant, il attaquera le premier robot de la liste.
• isAlive() qui renvoie true si la barre de vie est ">0".
• takeDamage(int damage) qui enlève les dégats (damage à la barre de vie du robot. Le robot barre de vie ne peut pas descendre en dessous de 0.

Écrire la classe Robot correspondant aux indications. Dans la suite de l'examen cette classe va peut-être évoluer. Pensez bien aux principes vus en cours.

Implémenter un design pattern permettant de faciliter la construction d'un robot. En commentaire en haut de la classe Robot donnez le nom du design pattern que vous avez utilisé.

Dans la méthode main d'une classe Main, construisez deux robots: un de moins de 1000g appelé bob et l'autre de plus de 1000g appelé alice.

On veut permettre à l'utilisateur de choisir la manière dont leur robot choisit sa cible dans chooseTarget. Certains utilisateurs voudront par exemple prendre un robot au hasard dans la liste, d'autres vont vouloir prendre le robot avec la plus grande attaque (ATT), ...

Mettez en place un design pattern permettant de donner cette liberté au créateur des robots. Vous n'utiliserez pas d'héritage pour cette question. En commentaire en haut de la classe Robot donnez le nom du design pattern que vous avez utilisé. Pensez bien à adapter le code des questions 1 et 2. On voudrait que par défaut, le comportement soit celui de prendre le premier de la liste.

Dans le main de votre classe Main, mettez l'ancien code en commentaire et construissez alice et bob en faisant en sorte que bob choisisse un robot au hasard et alice prenne celui qui a la plus petite défense.

Pour cette question, on veut résoudre le même problème qu'à la question précédente mais en utilisant l'héritage. Copier vos classes Robot et Main dans un package fr.uge.poo.ex1.inheritance. Proposez deux classes qui permettront de construire alice et bob. Dans le main de la classe Main, vous construirez alice et bob.

Vous n'utiliserez plus l'approche par héritage dans la suite de l'exercice.

On vous demande de rajouter la posibilité de logger les actions du robot (c'est-à-dire quand le robot prend des dégats ou quand il choisit sa cible). Tout le monde veut logger sur la console mais les gens ne sont pas d'accord sur le format des logs.

Certains veulent le format suivant:

  bob took 12 damages
  bob selected alice from [alice]

d'autres veulent:

  bob took 12 damages and has now 88 life points
  bob selected alice

Vous savez qu'il y aura encore plusieurs formats d'affichage dans l'avenir.

Comme les choses ne sont jamais simples dans la vie, vous avez plusieurs contraintes. Des robots ont déjà été construits avec votre code des questions précédentes et il est hors de question de toucher une ligne de ce code. De plus, il y a déjà du code qui manipule des robots qui est en production. Il est là encore, hors question de toucher à ce code.

Implémenter un design pattern qui vous permettra de rajouter les logs aux robots et donnez son nom en commentaire en haut de la classe Robot.

Dans le main de votre classe Main, faites en sorte qu'alice soit logger avec le premier format de log et bob avec le second.

Après une réunion avec vos chefs, vous apprenez que tout le monde n'est pas non plus d'accord sur où stocker les logs. Votre chef vous avez assuré que tout le monde voulez écrire sur la console mais ce n'est pas le cas. Certains veulent afficher dans la console, d'autres dans un fichier et d'autres dans les deux. Il est fort probable que dans l'avenir qu'on vous demande d'envoyer les logs en plus par discord, ... Il va donc falloir respecter le principe open close.

Modifier votre architecture logicielle pour pouvoir facilement prendre en compte ces modifications. Dans le main de votre classe Main, faites en sorte que alice soit loggée sur la console et bob sur la console et dans un fichier nommée bob.txt". Pour ne pas vous embéter avec la gestion des fichiers, au lieu d'écrire dans le fichier vous pouvez simplement mettre To write in bob.txt avant d'afficher sur la console. Nous savons que vous savez écrire dans un fichier.

Pour vérifier que votre architecture est adaptée, on vous demande d'envoyer en plus les logs d'alice et de bob sur Discord. Les logs d'alice iront sur le serveur Alice4ever et les logs de bob sur bob4life. On ne vous demande biensûr pas d'envoyer les messages sur Discord mais d'écrire dans la console To send on Discord to server Alice4ever : avant le message.

Combat

Toutes vos classes pour cet exercice doivent être dans le package fr.uge.poo.ex2.

Dans cette exercice et dans tous les autres, l'utilisation des switch de Java 17 est interdite.

Dans cet exercice, on s'intéresse à modéliser les combats entre plusieurs robots.

Commencez par copier vos classes dans le package de cet exercice.

Un combat n'a initialement aucun participant, on peut inscrire des Robot tant que le combat n'a pas commencé (il ne peut pas y avoir deux robots inscrits ayant le même nom), une fois que le combat commence, il fonctionne par round (tour en français) jusqu'à ce qu'il ne reste qu'un seul Robot. Lors d'un round, on prend les robots vivants dans l'ordre décroissant de leur vitesse (SPD). Pour chacun des robots (s'il n'est pas mort pendant le round), on lui demande de choisir sa cible (avec sa méthode chooseTarget parmis les autres Robot vivants et il inflige autant de dégats à la cible que son attaque moins la défense du robot qu'il attaque. Par exemple si un robot avec une attaque de 50 attaque un robot avec une défense de 40, il fera 10 dégats à ce robot.

La classe Fight aura donc les méthodes suivantes:

• une méthode register(Robot) qui inscrit un Robot au combat,
• une méthode start() qui lance le combat et simule les rounds jusqu'à ce que tous les robots soit mort sauf un ou qu'on ait fait 100 rounds sans gagant.
• une méthode Optional<Robot> winner() renvoie le gagnant du combat s'il est terminé et qu'il y a eu un gagnant.

Ecrivez la classe Fight comme décrite ci-dessus. Dans le main de la classe Main, créez un combat entre alice, bob et charlie (un nouveau robot). Démarrez le combat et affichez le gagnant.

On vous demande maintenant de rajouter plusieurs fonctionnalités:

• au début du combat, on veut envoyer un mail pour donner la liste des robots participants au combat.
• à la fin du combat, on veut mettre un post sur Facebook avec le vainqueur du combat.
• à la fin d'un round, on veut afficher la liste des robots morts pendant le round.

On ne fera pas d'appels aux API de Mail, Twitter ou Facebook. On affichera juste dans la console en mettant "To write to Facebook" avant le message, ...

Pourquoi est-ce qu'il ne serait pas une bonne idée de mettre toutes ces fonctionnalités dans la classe Fight ? Répondez en commentaire en haut de la classe Fight.

Proposez une architecture logicielle permettant de mettre en place toutes ces modifications et qui respecte les principes SOLID. En commentaire dans la classe Fight, donnez le nom du design pattern utilisé.

Dans la méthode main de la classe Main, montrez comment cette nouvelle architecture va être utilisée pour faire le même combat mais avec les modifications demandées.

Votre compagnie voudrait pouvoir influer sur les combats. Elle voudrait pouvoir changer les robots que peuvent cibler les autres robots. Par exemple, elle voudrait que les robots sponsorisés par ECorp ne soit pas proposer comme cible aux autres robots s'il y a des robots disponibles qui ne sont pas sponsorisés par e-corp.

Proposez une evolution de votre classe Fight qui permette de mettre place ce type de restrictions en respectant les principes SOLID. Créer un nouveau combat avec la restriction proposée en exemple dans le main de votre classe Main.