Refactoring de la classe Person pour distinguer les Agents des Admins
Description du problème
La classe Person
est actuellement trop généraliste. Il faut diviser la classe pour faire la distinction entre les agents et les administrateurs. Cela permet de supprimer les InvalidClassException
et de restreindre l'accès aux méthodes aux rôles qui n'y sont pas autorisés.
Choix des tests à effectuer
Pour les deux classes :
- Vérifier les méthodes
equals
ethashCode
Pour la classe Person
:
- Vérifier les méthodes
setName
etgetName
- Lorsque le nom est vide ou null
- Lorsque le nom est correct
Pour la classe Agent
:
- Vérifier la méthode
addTravel
Pour la classe Admin
:
- Vérifier la méthode
addTravelTo
Nous allons également modifier les tests des autres classes qui utilisent Person
.
A noter que nous ne testerons pas les méthodes getCalendar
et setCalendar
qui font l'objet d'une autre issue.
Solution à mettre en œuvre
Il faut créer deux nouvelles classes qui héritent de la classe Person
: Admin
et Agent
.
On choisit alors de supprimer les méthodes getCalendar
, setCalendar
, addTravelTo
, equals
et hashCode
de la classe Person
pour les déplacer :
- Les méthodes
getCalendar
etsetCalendar
sont déplacées dans la classeAgent
. - La méthode
addTravelTo
est déplacée dans la classeAdmin
. - Les méthodes
equals
ethashCode
sont modifiées dans les deux classes.
Modification identique pour les deux nouvelles classes :
- On modifie les méthodes
equals
ethashCode
:- Pour
hashcode
: on retire le code qui ne correspond pas à la classe considérée - Pour la classe
Admin
: on ne garde que le hash avec les attributsname
etrole
puisqu'un administrateur ne voyage pas, il ne possède pas de calendrier - Pour la classe
Agent
: on conserve le hash avec les attributsname
,role
etcalendar
puisqu'un agent possède un calendrier de voyages pour voyager - Pour
equals
: on supprime la dernière conditionif
puisqu'elle vérifiait le rôle d'une personne, or nous savons désormais le rôle d'une personne en fonction de la classe dans laquelle nous sommes. L'exceptionInvalidClassException
n'est donc plus nécessaire. - Pour la classe
Admin
: La variableperson
est remplacée par unadmin
et on vérifie que, pour deux administrateurs, leursname
etrole
sont égaux. - Pour la classe
Agent
: Par analogie, la variableperson
est remplacée paragent
et on vérifie que pour deux agents, leursname
etrole
sont égaux, mais aussi leurcalendar
puisqu'un agent possède un calendrier contrairement à un administrateur.
- Pour
- Pour les constructeurs de
Admin
etAgent
on fournit seulementname
et le rôle est explication attribué selon la classe.
Modification de la classe Agent
:
- On ajoute seulement la méthode
addTravelTo
qu'on renomme enaddTravel
où l'on ajoute untravel
, donné en paramètre, dans le calendrier de l'agent considéré. Il n'y a plus d'exceptionInvalidClassException
levée. - De plus, un agent voyage et possède donc un calendrier de voyage. On ajoute donc les méthodes
setCalendar
etgetCalendar
où l'on supprime la condition vérifiant le rôle de la personne puisque le rôle dépend maintenant de la classe considérée (Agent
ouAdmin
). Il n'y a plus d'exceptionInvalidClassException
levée.
Modification de la classe Admin
:
- Comme pour la classe
Agent
, on ajoute la méthodeaddTravelTo
où l'on fournit aussi unagent
en paramètre afin d'ajouter un voyage dans le calendrier d'un l'agent donné.
Issue numéro 8 dans l’énoncé