TP 3-4 — Énums et encapsulation

Objectif des TP : mettre les énumérations et l'encapsulation au service de la réutilisation — une Task enrichie de TP en TP, une classe fournie sous forme de jar qu'il faut savoir intégrer et lire sa documentation.

TP 3 — Cadre : dépôt GitLab et paquetage

Toutes les classes du TP vivent dans le paquetage tp03 — un paquetage par TP désormais. Le dépôt GitLab est constitué et alimenté un commit par exercice, avec des messages imposés : tpOO-03::exo-static, tpOO-03::exo-Task, tpOO-03::exo-ToDoList.

TP 3 — Card et LocalDate

Les enums Color (CLUB, DIAMOND, HEART, SPADE) et Rank (SEVEN à ACE) sont fournies dans l'énoncé. Card les combine et impose une surcharge de constructeur :

public Card(Color color, Rank rank) { /* ... */ }
public Card(String color, String rank) { /* via valueOf */ }

La classe UseCard fournie valide equals. L'exploration de LocalDate passe par la javadoc : distinguer les méthodes statiques (now, of) des méthodes d'instance, comparer deux dates chronologiquement, ajouter une durée (plusDays), calculer un écart avec until et l'enum ChronoUnit (paquetage java.time.temporal), créer une date aléatoire dans les 30 dernières années.

TP 3 — Task : statuts et numéro automatique

Task rejoue le compteur d'instances du cours 3 : idTask est un numéro automatique. Les deux constructeurs fixent les valeurs par défaut — créée à la date du jour, échéance à 10 jours plus tard, statut initial TODO — seul le couple (description, durée) est essentiel ; le constructeur long prend création, échéance et durée. L'affichage attendu est T<id> = <description>:<status>(<duration>):<deadline>.

L'enum TaskStatus (TODO, ONGOING, DELAYED, FINISHED) donne tout son intérêt à changeStatus() sans paramètre : passer au statut suivant dans l'ordre de déclaration se calcule avec ordinal() et values(). La surcharge changeStatus(TaskStatus) force un statut précis. Deux méthodes complètent la classe : isLate(), qui ne doit jamais renvoyer true pour une tâche achevée (tester le statut avant la date), et delay(int nbDays), qui repousse l'échéance.

L'exercice complémentaire ToDoList stocke les tâches dans un tableau initial de 5 cases, agrandi de 5 en 5 (enlarge) : ajout en première case libre, suppression par null — les tâches ne sont donc pas forcément contiguës. S'y ajoutent getNbTask, isOverwhelmed, dueTasks (échéances du jour), onSickLeave (report global) et trois tris : ancienneté, urgence, durée.

TP 4 — Encapsulation en cascade

L'exercice 1 empile trois encapsulations successives, chacune sans modifier la classe encapsulée :

1. Person : identifiant automatique, prénom, nom ; accesseurs et mutateurs — sauf sur l'ID, immuable ; toString sous la forme <id>: <forename> <name> et equals par identifiant seul, quel que soit le nom. La classe de test UsePerson est fournie sous Moodle.
2. Student encapsule un Person privé plus un tableau de notes sans case vide. Des trois constructeurs demandés, celui qui reçoit un Person en paramètre doit passer private : il exposerait l'objet encapsulé à l'extérieur. Viennent ensuite les méthodes déléguées, un equals sur tous les champs (en déléguant à Person.equals et en s'aidant de la boîte à outils Arrays), getAverage (0 sans note) et addGrade avec réallocation du tableau.
3. StudentAbs encapsule le Student plus un nombre d'absences ; toString s'appuie sur le toString de l'étudiant, equals sur son equals. Les seuils font la différence : warning(thresholdAbs, thresholdAvg) déclenche si absences ≥ seuil ou moyenne ≤ seuil, validation exige strictement moins d'absences et strictement mieux en moyenne — lire les signes au mot près.
4. YearGroup agrège une liste de StudentAbs — et l'énoncé le signale : ce n'est plus de l'encapsulation, juste une association. addStudent (unitaire et en liste), addGrades(double[]) qui répartit les notes dans l'ordre des étudiants, et validation(int, int) qui affiche les validés.

TP 4 — Un jar fourni : PendingCaseQueue

L'exercice 2 réutilise l'archive tp04-res.jar, qui contient la classe compilée PendingCase (paquetage tpOO.tp04), documentée par la javadoc de tp04-doc.zip à ouvrir via index.html. Lire la documentation avant d'écrire le code : c'est une partie de l'exercice.

PendingCaseQueue encapsule un tableau initialisé à null, une capacité commune à toutes les instances (10 par défaut, donc static) et un indice idx pointant la prochaine insertion. Ajouter décale idx vers la droite ; retirer décale tous les éléments restants vers la gauche et ramène idx d'un cran — le schéma de l'énoncé (file de capacité 4, retrait puis ajout) mérite d'être reproduit à la main avant de coder. Les méthodes se déduisent du modèle : clear, isEmpty/isFull, size, addOne, removeOne (renvoie null si la file est vide — l'énoncé conseille de décomposer le code), toString dans l'ordre, getTotalAmount, et la facétieuse cheating(PendingCase, position) qui insère à une place donnée pour passer avant tout le monde — à condition que la file ne soit pas pleine. La classe UsePendingCaseQueue fournie teste les cas limites (file de capacité 3, 4 dossiers en attente).