Principes SOLID

• Single Responsability Principle (SRP)
• Open/Close Principle (OCP)
• Liskov's Substitution Principle (LSP)
• Interface Segregation Principle (ISP)
• Dependency Inversion Principle (DIP)

Les exemples utilisés pour illustrer les 5 principes sont

• écrit en TypeScript.
• Extrait ou legerement adapté d'exemple existants (CF REF)
• Sont juste là pour illustrer un principe

Single Responsability Principle (SRP)

A CLASS SHOULD HAVE ONLY ONE REASON TO CHANGE.

Exemple

Ici on manipule une classe Personne

• pour acceder à ses caracteristiques (Nom, Prenom, Age, ...),
• pour calculer d'autres informations, pas forcement en rapport avec les caracteristiques de base de la classe
• et pour faire persister ces infos en base de donnée (par exemple).

Red Code

Voici à quoi cela peut ressembler si on "sépare les responsabilités"

Green code

Open/Close Principle (OCP)

SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.) 
- SHOULD BE OPEN FOR EXTENSION 
- BUT CLOSED FOR MODIFICATION.

Exemple

Ici on considère une classe PersonneFilter qui permet à partir d'une liste de personnes de les filter

• par leur age minimum
• ou par leur nom

Red Code

Le problème qu'on a ici, c'est que

• pour "etendre" les fonctionnalités de la classe, on doit la modifier (nouveau filtre)
• pour modifier un filtre (filtrer par nom et prenom), on remets potentiellement en cause l'integrité de la classe entière.

Voici comment on peut s'en dépatouiller

Green code

Liskov's Substitution Principle (LSP)

FUNCTIONS THAT USE POINTERS OR REFERENCES TO BASE CLASSES
MUST BE ABLE TO USE OBJECTS OF DERIVED CLASSES
WITHOUT KNOWING IT.

Exemple

Red Code

Green code

Interface Segregation Principle (ISP)

CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES
THAT THEY DO NOT USE.

Exemple

Ici on aborde le sujet classique du CRUD pour les accès aux données

Red Code

Avoir à implementer les methodes CRUD alors qu'on ne fait de la lecture pourrait paraitre absurde, mais bien souvent on se retrouve à les coder sans les utiliser.

c'est pas très écolo

Green code

Dependency Inversion Principle (DIP)

A. HIGH LEVEL MODULES SHOULD NOT DEPEND UPON LOW LEVEL MODULES. 
BOTH SHOULD DEPEND UPON ABSTRACTIONS.

B. ABSTRACTIONS SHOULD NOT DEPEND UPON DETAILS. DETAILS SHOULD DEPEND UPON ABSTRACTIONS.

Principe d'Hollywood

"Ne nous appelez pas, nous vous appellerons"

Exemple

Red Code

Green code

Quelques References

Robert C. Martin (Uncle Bob)

• Clean Code
• Agile Principles, Patterns, and Practices in C#
• The Principles of OOD

Christophe Héral : Comment rendre testable du code qui ne l'est pas ?

Olivier AZEAU Le script de l'atelier Si t'es pas SOLID, t'es pas AGILE

Wikipedia notamment pour les References

• https://www.codavel.com/2018/08/01/solid-open-closed-principle/
• https://www.tomdalling.com/blog/software-design/solid-class-design-the-single-responsibility-principle/
• https://www.tomdalling.com/blog/software-design/solid-class-design-the-open-closed-principle/
• https://www.tomdalling.com/blog/software-design/solid-class-design-the-liskov-substitution-principle/
• https://www.tomdalling.com/blog/software-design/solid-class-design-the-interface-segregation-principle/
• https://www.tomdalling.com/blog/software-design/solid-class-design-the-dependency-inversion-principle/