:: Enseignements :: Master :: M1 :: 2019-2020 :: Programmation Orientée Objet - Design Patterns ::
![[LOGO]](http://igm.univ-mlv.fr/ens/resources/mlv.png) | Jouons ! |
Ce TD se déroule en autonomie.
Les rendus sont à faire sur la plate-forme elearning.
TODO lien sur elarning TODO
Les consignes précises du rendu :
- UN seul zip pour l'ensemble des sources + schémas UML en PlantUML + readme au format MarkDown + ...
- nommage du zip: NOM_PRENOM-td1.zip
Ce TD permet d'approfondir les notions de hierarchie de types et
d'apprendre à faire des diagramme de classes UML.
Le rendu est à faire sur la plate-forme elearning avant dimanche minuit (les dépôts sont refusés après)
Ce qui est attendu : code dans un zip + 1
page max d'explications
(comment vous avez fait *et* pourquoi vous avez fait comme ça !) +
photo de votre UML fait sur une feuille.
Attention, Achtung ! Warning !,
pour vos diagramme UML, vous ne devez indiquer que les
relations qui sont intéressantes
et non pas toutes les relations
possibles comme vous le sortirait un
logiciel de dessin automatique de
diagramme UML (on doit sentir l'intelligence ici).
Exercice 1 - Enfin la paye
On souhaite modéliser la paye des employés d'une entreprise.
Chaque
employé possède un nom (pour le debug) un salaire et un bonus
optionnel, le salaire total
d'un employé est la somme de son salaire
et de son bonus s'il existe.
La somme totale que soit verser
l'entreprise à la fin d'un mois est la
somme de la paye de chaque
employé.
Un boulot de première modélisation a déjà été effectué par votre chef
de projet sous la forme des classes
Employee,
Bonus et
Payment.
Employee.java
Bonus.java
Payment.java
Ainsi qu'un main de test
public static void main(String[] args) {
Payment payment = new Payment();
Employee bob = new Employee("bob", 90);
Employee marta = new Employee("marta", 80);
Employee carol = new Employee("carol", 120);
payment.addEmployee(bob);
payment.addEmployee(marta);
payment.addEmployee(carol);
bob.setSalary(100);
marta.setBonus(new Bonus(30));
System.out.println(payment.getAllEmployees());
//System.out.println(payment.totalPayment());
}
-
Faire sur une feuille blanche une modélisation UML des
relations entre les différentes classes.
Rudiment d'UML
à partir de la page 16.
-
#EXPLICATIONS Décrire en une phrase la responsabilité de chaque classe.
#EXPLICATIONS Puis décrire en un court paragraphe, les relations entre les
classes.
#UML Puis utiliser le smartphone de votre voisin (où le votre) pour
récupérer l'image de votre modélisation UML
pour l'inclure dans votre
rapport comme appui visuel à ce que vous venez
d'écrire.
-
Expliquer
-
#EXPLICATIONS Pourquoi le champs amount de Bonus
et le champs name de Employee sont déclarés final
-
#EXPLICATIONS Pourquoi il y a 1 test pour savoir si amount est négatif
dans Bonus et deux tests pour savoir si salary
est négatif dans Employee ?
#EXPLICATIONS Que faire pour éviter la (petite) duplication de code ?
-
#EXPLICATIONS A quoi sert l'appel à la méthode
Objects.requireNonNull
dans
Employee
et dans
Payment
?
-
#EXPLICATIONS Pourquoi
Payment.getAllEmployees
ne renvoie pas directement la référence sur
employees
mais fait un appel à
Collections.unmodifiableList
?
-
#EXPLICATIONS Expliquer pourquoi il n'y a pas de getters (de méthode
getXXX) dans Bonus ou Employee ?
-
Avant de commencer l'implantation, on peut remarquer qu'il est
possible de créer un
Employee
mais d'oublier de l'ajouter dans une instance de
Payment
.
On souhaite changer l'API pour ne pas permettre de créer un
Employee
qui ne sera pas enregistré.
#CODE Si vous préferrez, la méthode d'ajout doit créer un employé *et*
ajouter celui-ci dans Payment.
De plus, il ne
doit pas y avoir d'autre moyen
de créer un employé que de passer par
la méthode d'ajout.
-
#CODE On vous demande d'ajouter le calcul de la paye totale à la classe
Payment
,
#EXPLICATIONS Pour cela, ecrire un paragraphe sur la façon dont il faut écrire le
code
pour ne pas allez à l'encontre
des responsabilités des classes
que vous avez décrites précédemment.
-
L'entreprise accueille aussi des étudiants qu'il faut payer.
Comme les employees classiques, ils ont un salaire et peuvent
avoir un bonus mais par contre, lors du calcul de la paye,
l'entreprise ne payera que la moitié de leur salaire,
le reste étant payé par l'état.
Dans un premier temps, on cherche à faire un design
sans factorisation technique de code (pas de classe abstraite SVP !).
#EXPLICATIONS Indiquer en un paragraphe comment il faut modifier le diagramme des
classes et #UML produisez sur une nouvelle feuille blanche une version UML
du nouveau diagramme
de classes
dont vous ferez aussi une photo.
-
#CODE Implanter la solution retenue.
-
#CODE Modifier votre implantation pour éviter la redondance de code
sans changer l'interface (au sens général) du code que vous avez
produit précédemment.
#EXPLICATIONS Pourquoi dit-on que "l'héritage n'est pas un outil de design" ?
-
Enfin, certain étudiants sont embauchés après leur étude et donc leur "status" passe de Student
à Employee.
#EXPLICATIONS Est ce que l'architecture de classes que vous avez produite précédemment
permet de s'adapter à ce nouveau scénario.
#UML Proposer un nouveau diagramme UML (n'ayez pas peur de casser des choses
ou de repartir de votre premier diagramme UML)
#CODE puis écrire l'implantation correspondante.
#EXPLICATIONS Pourquoi un petit changement dans la specification comme celui-ci peu entrainer des changements majeur dans la modélisation,
comment faire pour éviter ce problème (non, la solution n'est pas d'"être générique").
© Université de Marne-la-Vallée