Jouons !

• UN seul zip pour l'ensemble des sources + photos UML + readme au format MarkDown + ...
• nommage du zip: NOM_PRENOM-td1.zip

Exercice 1 - Enfin la paye

				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());
				}
			

1. Faire sur une feuille blanche une modélisation UML des relations entre les différentes classes.
   Rudiment d'UML à partir de la page 16.
2. Décrire en une phrase la responsabilité de chaque classe.
   Puis décrire en un court paragraphe, les relations entre les classes.
   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.
3. Expliquer
   • Pourquoi le champs amount de Bonus et le champs name de Employee sont déclarés final
   • 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 ?
     Que faire pour éviter la (petite) duplication de code ?
   • A quoi sert l'appel à la méthode Objects.requireNonNull dans Employee et dans Payment ?
   • Pourquoi Payment.getAllEmployees ne renvoie pas directement la référence sur employees mais fait un appel à Collections.unmodifiableList ?
   • Expliquer pourquoi il n'y a pas de getters (de méthode getXXX) dans Bonus ou Employee ?
4. 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é.
   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.
5. On vous demande d'ajouter le calcul de la paye totale à la classe Payment , 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.
6. 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 !). Indiquer en un paragraphe comment il faut modifier le diagramme des classes et produisez sur une nouvelle feuille blanche une version UML du nouveau diagramme de classes dont vous ferez aussi une photo.
7. Implanter la solution retenue.
8. 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.
   Pourquoi dit-on que "l'héritage n'est pas un outil de design" ?
9. Enfin, certain étudiants sont embauchés après leur étude et donc leur "status" passe de Student à Employee. Est ce que l'architecture de classes que vous avez produite précédemment permet de s'adapter à ce nouveau scénario. Proposer un nouveau diagramme UML (n'ayez pas peur de casser des choses ou de repartir de votre premier diagramme UML) puis écrire l'implantation correspondante.
   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").