SRP : Single Responsibility Principle​ Une classe doit avoir une et une seule responsabilité​ OCP : Open/Close Principle​ Une entité doit être ouverte aux extensions et fermée aux modifications​ LSP : Liskov Substitution Principle​ Les sous-types doivent être interchangeables par leurs types de base​ ISP : Interface Segregation Principle​ Un client ne doit pas être forcé de dépendre de méthodes qu’il n’utilise pas​ DIP : Dependency Inversion Principle​ Il faut dépendre des abstractions, pas des implémentations​

1. S.O.L.I.D.
MAITRISEZ VOTRE PROGRAMMATION OBJET

2. Définition
• SOLID est un acronyme qui désigne les 5 premiers principes de la
programmation orientée objet décrit par Robert Cecil Martin (Oncle
Bob)
• Il n’existe pas de hiérarchie dans ces principes
• Dans la pratique ces principes sont très imbriqués

3. 5 principes
• SRP : Single Responsibility Principle
Une classe doit avoir une et une seule responsabilité
• OCP : Open/Close Principle
Une entité doit être ouverte aux extensions et fermée aux modifications
• LSP : Liskov Substitution Principle
Les sous-types doivent être interchangeables par leurs types de base
• ISP : Interface Segregation Principle
Un client ne doit pas être forcé de dépendre de méthodes qu’il n’utilise pas
• DIP : Dependency Inversion Principle
Il faut dépendre des abstractions, pas des implémentations

4. Avant de commencer
• SOLID s’articule au cœur d’une architecture orienté objet, ses
principes sont un tremplin vers une certaine sérénité
• On peut considérer ces principes comme un « art de faire », de
bonnes pratiques
• « Principe », pas pattern. Si SOLID va nous dire ce qu’il faudrait faire,
les patterns vont nous dire comment le faire
• Utiliser ces principes demande de les conserver à l'esprit durant
chaque étape de nos développements
• Le pragmatisme doit rester maitre, une architecture trop complexe
peut en réalité nuire à ce pourquoi SOLID existe : la maintenabilité

5. Single Responsibility Principle
SRP – LA RESPONSABILISATION DE VOS CLASSES

6. SRP : Single Responsibility Principle
• Principe de responsabilité unique : une classe ne doit changer que
pour une seule raison
• Un moyen de trouver les raisons qui pourraient conduire la classe à
changer est d'analyser l'audience de la classe
SRP

7. SRP : Single Responsibility Principle
L’idée est que si une responsabilité évolue, alors on ne risque pas de
casser les autres pour avoir introduit des couplages forts comme du
code imbriqué le ferait.
• plus compréhensible car découpé, responsabilité par responsabilité
• testable plus facilement avec un spectre fonctionnel réduit
• plus facile à étendre

8. SRP : Single Responsibility Principle
Le respect excessif du principe d'unique responsabilité peut conduire à
de l'optimisation prématurée, une mauvaise conception et une
architecture qui se retrouve difficile à comprendre.
En revanche, les responsabilités techniques (non-métier), telles que la
persistance, les logs, l’accès aux données, etc. sont presque toujours à
scinder dès le début.
Ici, 2 responsabilités (gestion de la connexion
et de la communication) qui ne doivent pas
nécessairement être scindées. Cela dépendra
le l’évolution future de l’application.

9. Open/Close Principle
OCP – LA MODIFICATION PAISIBLE

10. OCP : Open/Close Principle
• Une classe doit être ouverte à l'extension, mais fermée à la
modification
• Sauf pour la correction de bug, l’idée est de ne jamais modifier un
code déjà existant surtout s’il a déjà été testé et approuvé
• Faire bon usage de l’abstraction et du polymorphisme afin d’étendre
un comportement sans le modifier (Decorator, Factory, Observer).
• La composition avec le pattern Strategy répond aussi à ce principe

11. OCP : Open/Close Principle
Il est probable que vous passiez plus de temps à ajouter de nouvelles
fonctionnalités que d’écrire du code neuf. Ce principe s’applique à
structurer notre code afin de nous procurer l'un des plus grands
avantages de la programmation orientée objet : la réutilisation et la
maintenabilité.
OCP

12. Liskov Substitution Principle
LSP – LA RÉCONCILIATION DES ENFANTS

13. LSP : Liskov Substitution Principle
• Les sous-types doivent être interchangeables par leurs types de base
• Les classes enfants ne doivent jamais briser les définitions de type de
classe parente

14. LSP : Liskov Substitution Principle
Ne pas penser « tous les oiseaux volent sauf l’autruche » mais plutôt
« tous les oiseaux ne volent pas, l’autruche en est un »
LSP

15. LSP : Liskov Substitution Principle
Je dois pouvoir considérer un cercle, un rectangle ou un carré comme
n’importe quelle forme.
LSP

16. Interface Segregation Principle
ISP – L’ANTI OUTIL A TOUT FAIRE

17. ISP : Interface Segregation Principle
• Un client ne doit pas être forcé de dépendre de méthodes qu’il
n’utilise pas
• Préférer plusieurs interfaces spécifiques pour chaque client plutôt
qu'une seule interface générale : interfaces de tête vs interfaces de
rôle
• Créer des interfaces à grains fin qui sont spécifiques au client

18. ISP : Interface Segregation Principle
Un client ne doit pas être forcé de dépendre de méthodes qu’il n’utilise
pas
LSP

19. DIP : Dependency Inversion Principle
DIP – L’EMERGENCE DES ABSTRACTIONS

20. ISP : Interface Segregation Principle
• Il faut dépendre des abstractions, pas des implémentations
• L'idée est que chaque point de contact entre deux modules soit
matérialisé par une abstraction
• Une abstraction se matérialise par une interface ou une classe de
base qui est aussi l’abstraction de classe plus élevé
• Les interfaces documentent

21. ISP : Interface Segregation Principle
Les modules de haut niveau ne doivent pas dépendre de modules de
plus bas niveau
ISP

22. Conclusion
• SOLID vs YAGNI (YouAren't Gonna Need It) : pourquoi mettre en
place tout un système de tolérance au changement dans un système
statique, avec peu de dépendances externes ?
• Il est possible de ne pas appliquer tous les principes SOLID d’un coup,
il n’est pas choquant d’ajuster les choix de conception au moment où
l’on en a besoin (refactoring)
• La raison, le pragmatisme et l’expérience vont nous permettre
d’arbitrer. Avec l’expérience vous pourrez appliquer
systématiquement SOLID avec le même effort, mais probablement
pas dès le début