ISSUE 3: Association bidirectionelle Calendar <-> Travel
Première version
Pour assurer l'association bidirectionnelle avec Travel
depuis Calendar
, il faudra avoir que ces classes soient fonctionnelles et prennent en compte tout les conditions à remplir pour chacune des méthodes, avant de les modifier pour y ajouter l'association.
Implémentation pour la classe Calendar
Dans CalendarTest
Dans un premier temps, j'ai commencé par ajouter une liste de tests vérifiant les setters, ajout et suppression des différents attributs contenus dans la classe, pour ainsi avoir une base pour commencer à remanier les différentes méthodes au sein de Calendar
.
Dans Calendar
Pour faire fonctionner la totalité des tests dans Calendar
, j'ai principalement eu a ajouter des exceptions dans selon les cas:
- Le constructeur: Ajout d'exception dans le cas où owner est null ou n'est pas un agent, on envoie une Exception
- getOneTravel (ajouté) Cette méthode à été ajouté pour pouvoir accéder au _i_ème travel parmis ceux possédé par un Agent. Dans le cas où l'indice excède la taille actuelle de l'ArrayList, on envoie une Exception.
- setOwner : On envoie une Exception si le futur Owner est autre qu'un agent.
-
addTravel: On envoie une Exception si le nombre de
Travel
déja stocké est égal à MAX_TRAVEL_VALUE (explaining variable permettant de déterminer le nombre maximal deTravel
pour un Agent). -
removeTravel: La méthode renvoie une Exception si la liste de trajets est nulle, si ce trajet n'est pas contenu dans la liste ou si on tente d'effacer un trajet sans parent (supposément impossible après ajout de l'association). Il fait appel a unsetParent de la classe
Travel
, qu'on explicitera plus bas. -
basicRemove: Depuis la fonction unsetParent de la classe
Travel
, on fera appel a cette fonction pour supprimer proprement le trajet demandé.
Impémentation pour la classe Travel
Dans TravelTest
Comme pour CalendarTest
, les testes ont été créés dans un premier temps pour implémenter correctement les méthodes de Travel. Pour cet issue, les tests ajoutés seront uniquement ceux en rapport avec l'association avec Calendar
. Parmis ceux-ci, voici les test vérifiant le bon fonctionnement de l'association:
- checkAssociationConstructor: Vérifie que l'association se fait bien lors de la construction d'un objet. Dans le cas où cette association est réussi, on doit supposément avoir l'attribut calendar comme parent du trajet construit, et ce trajet doit bien avoir été ajouté dans la liste des trajets de calendar.
- checkAssociationWithSetter: On vérifie avant et après l'utilisation de setParent que le changement de propriétaire du calendrier c'est bien fait, et que l'association a bien été modifiée pour se faire entre le trajet actuel et le nouveau propriétaire (et que l'ancien propriétaire n'est plus associé à ce trajet)
Les autres tests vérifient qu'on essaye bien d'associer un trajet à un Agent, que cet Agent n'a pas un calendrier plein.
Dans Travel
Pour que Travel
fasse bien l'association avec Calendar
, il fallu modifier plusieurs méthodes ainsi que le constructeur:
-
Le constructeur: Pour construire
Travel
, on vérifie d'abord que le parent existe bien et, si oui, on l'ajoute dans un attribut pour garder une trace. Puis on fait appel à addTravel depuis ce parent pour qu'il ajoute le trajet en train d'être construit dans sa liste de trajets. - setParent: Avant de d'attribuer un nouveau parent à un trajet, il faut supprimer l'ancienne association ainsi que retirer ce trajet de la liste de l'ancien parent. On fait donc un unsetParent pour supprimer celle-ci, suivi d'un basicSet pour ajouter le nouveau parent. Enfin on fait comme dans le constructeur: fait appel à addTravel depuis ce parent pour qu'il ajoute le trajet dans sa liste de trajets.
-
unsetParent: Fait appel à basicRemove depuis l'attribut parent pour supprimer de sa liste le trajet actuel. Puis il set le parent actuel a null pour être sûre que celui-ci ne reste pas au sein de
Trajet
. - basicSet: Passe un parent donné en paramètre à l'attribut parent.
NB: Lors du commit d536f4a3, les tests étaient tous vérifiés, mais nécessiterons des modifications après l'impémentation de Correspondence
NB2: Cette implémentation est suceptible de changer lors de la résolution du Ticket #11 (closed)
#11 (closed)
UPDATE SELON L'ISSUELes différentes classes explicités précédement ont été modifiées lors de l'ajout des classes Reference..To..
.
Pour plus d'information sur les modifications, se référer a l'ISSUE #11 (closed)