TP 2 — Classe, documentation et tests

Objectif du TP : écrire trois classes du paquetage tpQU.tp02 — WarriorCard, Event, Agenda — en documentant (javadoc) et en testant. La progression inverse les rôles au fil du TP : les tests de WarriorCard et Event sont fournis et valident votre code ; ceux de Agenda, c'est vous qui les écrivez.

1. WarriorCard : écrire, documenter, valider

Une carte de guerrier porte un name et deux entiers positifs, strength et agility. Le diagramme UML impose les signatures suivantes :

public class WarriorCard {
    public WarriorCard(String name, int s, int ag) { /* crée une carte complètement spécifiée */ }
    public boolean equals(Object obj) { /* équivalence basée UNIQUEMENT sur le nom */ }
    public int compareStrength(WarriorCard other) { /* 0, négatif ou positif */ }
    public int compareAgility(WarriorCard other)  { /* 0, négatif ou positif */ }
    public String toString() { /* <nom>[S=<strength>,A=<agility>] */ }
}

Q1 — le code, guidé par la spécification. equals compare uniquement le nom du guerrier représenté. compareStrength et compareAgility suivent la convention des comparateurs : 0 si équivalence, négatif si la carte courante est inférieure, positif si elle est supérieure. Et toString produit strictement la forme <nom>[S=<strength>,A=<agility>].

Q2 — la documentation. Commentez chaque élément suffisamment pour la génération, puis produisez la javadoc dans le répertoire doc — en ligne de commande ou depuis l'IDE, style par défaut :

javadoc -d doc src/tpQU/WarriorCard.java

La documentation s'enrichit de balises HTML : liens, images (diagrammes UML), gras, italique, feuille de style personnalisée.

Q3 — la validation. La classe de tests WarriorCardTest est fournie : intégrez-la au répertoire test de votre hiérarchie et exécutez-la. Elle fixe le contrat — une signature ou un format de toString qui dévie d'un caractère est signalé. Ses affichages sont purement optionnels : ils servent seulement à visualiser l'ordre d'exécution du code.

Q4 — le commit. « tpQU02::exo-WarriorCard », en n'incluant que les fichiers nécessaires. La javadoc étant générée, elle ne part pas sur Git : ajoutez la ligne doc sous la ligne bin du .gitignore.

2. Event : constructeurs chaînés et délégation

Un évènement est un fait qui survient à un moment donné, pour une certaine durée. Attributs : label, place, start et end en LocalDate, et tasks — une ToDoList. Si vous n'avez pas terminé le TP 3 de R2.01 (TaskStatus, Task, ToDoList, paquetage tpOO.tp03), l'archive res02-tpQU.jar est là pour être intégrée au projet.

Q1 — quatre constructeurs, chaînés vers le plus complet, « afin d'éviter toute redondance de code inutile ». Chaque niveau ajoute une valeur par défaut :

public Event(String label, String place, LocalDate start, LocalDate end, ToDoList tasks) {
    // si start est postérieur à end, end prend la valeur de start
}
public Event(String label, String place, LocalDate start, LocalDate end) {
    this(label, place, start, end, new ToDoList());   // liste vide si non spécifiée
}
public Event(String label, String place, LocalDate start) {
    this(label, place, start, start.plusDays(1));     // fin = début + 1 jour
}
public Event(String label, String place) {
    this(label, place, LocalDate.now());              // début = jour courant
}

Q2 et Q3 — interface et délégation. Générez accesseurs et mutateurs, écrivez un toString concis sous la forme <label>-<place>: <start>-<end> (autres attributs ignorés), puis les méthodes déléguées vers la ToDoList — addTask, removeTask, getChores, getNbTasks : Event enveloppe la liste sans la réimplémenter.

Q4 et Q5. equals(Object o) prend en compte tous les attributs sauf la liste des tâches. overlap(Event evt) retourne true si une partie de l'évènement courant se déroule en même temps que celui passé en paramètre ; il n'y a pas chevauchement si la fin de l'un est antérieure au début de l'autre, ou l'inverse. Une définition à encoder une fois — elle servira partout.

Q6 — téléchargez EventTest, intégrez-le au projet, validez. Q7 — commit : « tpQU02::exo-Event ».

3. Agenda : c'est vous qui testez

La classe Agenda stocke ses évènements dans une ArrayList<Event> et impose une discipline anti-chevauchement :

• toString() : tous les évènements, à raison d'un par ligne ;
• conflicting(Event evt) : détermine si l'évènement passé en paramètre ne chevauche aucun évènement déjà présent dans l'agenda ;
• addEvent(Event evt) et addEvent(Event evt, int idx) : ajout, éventuellement à une place donnée, s'il n'en chevauche aucun — minimisez la redondance en faisant tout faire par la version la plus générale ;
• removeEvent(Event evt), removeEvent(int idx), removeEvent(String label) : trois façons de désigner la victime ;
• removeOverlapping(Event evt) : supprime tous les évènements qui chevauchent celui fourni ;
• removeBetween(Event evt1, Event evt2) : supprime ceux chevauchant la période entre le début du premier et la fin du second ;
• enfin (Q7), l'agenda doit rester toujours trié par dates de début croissantes : insérez à sa place plutôt que de retrier après coup.

Q8 est le cœur de l'exercice : écrivez votre classe de tests AgendaTest pour valider conflicting et removeOverlapping. Les bonnes pratiques du cours s'appliquent : des noms de tests qui disent leur but, un seul assert par test — une seule raison d'échouer.

Q9 — commit : « tpQU02::exo-Agenda », puis poussez l'ensemble des modifications vers GitLab.