TP 7-8 — Collections

Objectif des TP : choisir et manipuler les bonnes collections — deux HashMap en parallèle pour un annuaire bidirectionnel, une Collection pour un élevage hétérogène, un HashSet quand l'unicité est une règle métier — et câbler equals/hashCode là où les structures en ont besoin.

TP 7 — Annuaire bidirectionnel

Le contexte restreint un recyclage : la classe PhoneNumber, fournie en jar (elle provenait d'un TD, paquetage tdOO.td01), est trop générique — pays 33, zone 03 et secteur 20 sont fixes pour l'université ; restent le code de composante (1 chiffre) et le numéro de poste (4 chiffres). En interne on ne compose que les 5 derniers chiffres ; en externe, tous.

1. L'enum UniversityDepartment (squelette fourni) porte les 8 composantes avec leurs indicatifs de 1 à 8 ; à compléter avec getDiallingCode(), getLabelShort() (le sigle) et getLabelLong().
2. ProPhoneNumber encapsule la PhoneNumber fournie : constructeur (String fourDigits, UniversityDepartment dept), puis les deux affichages imposés — internToString() : 31234(IUT) ; externToString() : +33.3.20.03.12.34 (Institut Universitaire de Technologies). Un equals(Object) classique plus une surcharge equals(String fourDigits) sur le seul poste. La classe de tests ProPhoneNumberTest est fournie.
3. BidirectionalPhoneBook repose sur deux tables gérées en parallèle : name2num : Map<String, ProPhoneNumber> et num2name : Map<String, String> (clé = les 5 chiffres internes). Chaque opération maintient les deux tables : add renvoie false si alreadyRegistered trouve la chaîne — nom ou 5 chiffres — dans l'une ou l'autre. Les recherches deviennent triviales dans les deux sens (getProPhoneNumberFromName, getNameFromFiveDigits), et listing() groupe les numéros par composante, nom long en tête, format interne sur chaque ligne.

La classe de tests BidirectionalPhoneBookTest est fournie.

TP 7 — Élevage de volailles

Poultry est abstraite : bague (identity) et weight sont communs et protected ; prix au kilo et seuil d'abattage sont propres à chaque espèce mais partagés par tous ses individus — ce sont donc des variables de classe (priceKg, slaughterThreshold) définies dans Duck (1,5 €/kg, 5 kg), Hen (1 €/kg, 3,5 kg) et Goose (4 €/kg, 10 kg), modifiables via setPriceKg et setSlaughterThreshold.

La décomposition du code fait l'exercice : la formule du prix (poids × €/kg) est identique pour toutes les espèces — getPrice() s'écrit une fois dans la mère, en invoquant des accesseurs aux variables de classe ; l'affichage Hen [1,2.3] passe par un toString lui aussi factorisé. Les classes de tests DuckTest, HenTest, GooseTest sont fournies.

BreedingFarm stocke ses bêtes dans une seule Collection<Poultry> (taille maximale 200 par défaut) : add si la limite n'est pas atteinte, getFarmSize, getNbDuck, search(int identity), getDuck(int i), updateWeight. Les questions financières imposent de filtrer par aptitude : potentialProfit() somme les bêtes dont le poids dépasse le seuil d'abattage, slaughtering() les retire de l'élevage et renvoie la List<Poultry> partie à l'abattoir. Le foie gras arrive par une interface IForceFeeding (oies et canards seulement) qui sert à calculer potentialLuxuryProfit() — le gain doublé sur les volailles concernées. La classe de tests BreedingFarmTest est fournie.

TP 8 — Mise en rayon : interface et Comparable

L'organisation est donnée par l'UML : l'interface IProduct (getPrice, isPerishable) unifie Food et Furniture pour que la mise en rayon soit un traitement unique — « sans faire de test pour déterminer son type réel », dit l'énoncé.

• Food : label null remplacé par refUnknownXXX (compteur de références inconnues), date limite par défaut à 10 jours de la date courante, isBestBefore(LocalDate), et l'affichage [pasta=3.25 -> before 2019-01-01].
• Le tri par date limite se fait en rendant Food Comparable : le programme UseComparable de l'énoncé doit réordonner le stock après un simple Collections.sort(storage) — les plus proches de péremption d'abord.
• Shelf : réfrigérée ou non, capacité maximale, ArrayList<IProduct> ; add(IProduct) vérifie compatibilité et place restante ; l'affichage attendu est [false : 1 -> []] (non réfrigérée, capacité 1, vide).
• Shop.tidy(ArrayList<IProduct>) répartit le stock sur les étagères ; closeBestBeforeDate(int nbDays) liste les périssables dont l'échéance approche. La classe de tests ShopTest est fournie.

TP 8 — Concours : HashSet et association réflexive

Participant porte une association réflexive partner (0..1) : matchWith doit câbler les deux côtés et renvoyer false si l'un des deux a déjà un partenaire ; breakOff délie les deux côtés aussi — « attention à la réflexivité ! », répète l'énoncé. hashCode et equals sont générés par l'IDE sur les bons attributs : c'est le préalable indispensable, car le vivier BreedingGround repose sur un HashSet et chaque participant ne peut s'inscrire qu'une seule fois (registration refuse les doublons).

Le reste des méthodes exploite cette unicité : loners() (participants sans partenaire), lonersCleansing(), forcedMatching() (appariement aléatoire des isolés), puis la chasse aux tricheurs entre deux viviers — cheaters (inscrits dans les deux), isolateCheaters (délier avant d'exclure !), cheatersCleansing — et les fusions : possibleMerging, fusion, securedMerging (bannir les tricheurs puis fusionner). La classe de tests BreedingGroundTest est fournie.

---