Les principes S.O.L.I.D.
Single responsability (responsabilité unique)
Open-Closed (ouverture-fermeture)
Liskov substitution (substitution Liskov)
Interface segregation (segrégation par interface)
Dependency inversion (inversion des dépendances)
Ne pas sous entendre ici que "chaque module doit juste faire une seule" car il y a un principe pour cela qui se nomme function ou fonction.
Comprendre plutôt qu'un module doit avoir une et seulement une raison de changer!
Les acteurs (utilisateurs) sont la raison de changement auquel ce principe fait référence.
Un module doit être responsable d'un et seulement d'un acteur!
Cas d'une class Employee de l'application payroll qui a 3 méthodes:
Cette classe enfreint le SRP car ces 3 méthodes s'adressent à 3 acteurs différents.
CFO souhaite faire modifier le calcul des heures non supplémentaires.
En revanche, le COO ne souhaite pas bénéficier de ce changement.
Un dev est chargé de faire le changement.
Il voit bien que regularHours() est appelée par calculatePay() mais ne voit pas qu'elle est également appelée par reportHours().
La changement est ok, les tests sont OK, le CFO valide que la méthode fonctionne comme souhaité, le système est déployé en PROD.
Bien sur le COO ne sait pas que ce changement a eu lieu et continu d'utiliser la fonction qui maintenant produit un résultat incorrect.
Le problème est détecté mais les mauvaises données ont entrainé un cout de plusieurs millions de dollar.
Le principe SRP dit de séparer le code auquel différents acteurs dépendent.
Le CTO souhaite modifier le schema de la table BD Employee.
Le COO souhaite modifier le format des heures reportées.
2 devs travaillent indépendament sur la même fonction entrainant une collision résultant d'un conflit de fusion.
Séparer le code qui dépend d'acteurs différents.
Les trois classes nont pas connaissances des autres.
Le pattern Facade. EmployeeFacade est responsable de l'instanciation et délégation des classes et fonctions.
Garder la méthode la plus importante (calculatePay) la plus proche des données tout en utilisant le pattern Facade pour les fonctions moins importantes.
p.61 Ch.7
Un artifact logiciel doit être ouvert à l'extension mais fermé à la modification.
Si composant A doit être protégé de tout changement dans le composant B, alors le composant B doit dépendre de composant A.
p.69 Ch.8
p.77 Ch.9
p.83 Ch.10
p.87 Ch.11