Ajout de classes References entre les différentes classes principales
Reference..To..
Implémentation des classes Les premières versions pour faire l'association bidimentionnelles implémenté directement au sein des classes Travel, Calendar, Correspondence n'étant pas propre ni concluantes lors des tests (notamment entre *Correspondence et Travel, j'ai ajouté de nouvelles classes modélisant ces associations. Ces classes implémentant les attributs MultipleReference<T>
et SingleReference<T>
précédement introduits dans le ticket #9 (closed).
Reference..To..
implémentant SingleReference<T>
Les Pour représenter les associtations unidirectionelles ou bidirectionelles n'associant qu'un unique attribut, on utilisera les classes références implémentant SingleReference<T>
. Celle-ci fonctionne simplement:
- On construit un objet
Reference..To..
au sein des classes qui prend en paramètre les deux attributs à associer. - On implémente les différentes méthodes (set(T newValue), basicSet(T newValue), unset() ..etc..) de manière à ce que lorsqu'un attribut est changé dans les classes
calendar
, ces modifications se font dans les deux sens (ex: pour ReferenceAgentToCalendar, lorsqu'on associe un nouveau calendrier à un agent, on s'assure que d'une part l'agent possède bien ce nouveau calendrier et , d'autre part, que ce calendrier à bien comme nouveau propriétaire l'agent donné et , si il avait un autre propriétaire avant ça, celui-ci ne l'est plus dorénavant.) - On s'assurera au sein des classes tests que ces associations se comportent correctement.
Reference..To..
implémentant MultipleReference<T>
Les A l'inverse, pour représenter les associtations possédant zéro/un à plusieurs attributs, on utilisera les classes références implémentant MultipleReference<T>
. Celle-ci fonctionne comme suit:
- On construit un objet
Reference..To..
au sein des classes qui prend en paramètre l'un des attributs à associer, et le second sera inséré dans une collection qui sera ensuite construit sous la forme d'un ArrayList ou autre, selon les besoins. - On implémente les différentes méthodes (add(T newValue), remove(), basiAdd(T newValue) ..etc..) de manière à ce que lorsqu'un attribut est changé dans les classes
calendar
, ces modifications se font d'une part sur l'attribut principal au travers de set(newValue) ou unset(), et d'autre part au sein de la collection associée, via leurs add(T newValue) ou remove(T value) pour s'assurer que cette valeur soit bien supprimé ou ajouté selon les besoins - Comme certaines associations ont des restrictions tel qu'un nombre maximum de valeurs pouvant êtres associé à un objet (ex:
Travel
ne peut avoir plus de 10 Correspondences etCalendar
ne peut avoir plus de 10 Travels) on ajoute une variable "inline" de type static final pour représenter cette capacité maximum, et une méthode associée. Cette variable servira à vérifier avant un ajout d'association que la capacité n'a pas déja été atteinte. - Comme précédement, on s'assurera au sein des classes tests que ces associations se comportent correctement.
UPDATE
Toute les classes étant précédemment implémentés au sein du package calendar
ont été déplacés dans un nouveau package **reference**
par soucis de cohérence (notamment pour le ReferenceAgentToCalendar, celui-ci n'ayant pas sa place au sein de calendar
.