Principes SOLID Flashcards
Principes SOLID
- SRP (Single Responsibility Principle)
- OCP (Open Closed Principle)
- LSP (Liskov Substitution Principle)
- ISP (Interface Seggregation Principle)
- DIP (Dependancy Inversion Principle)
Single Responsibility Principle (SRP)
Une classe ne devrait avoir qu’une seule raison de changer.
Le SRP ou principe de la responsabilité unique est probablement le plus connu et le plus
simple à comprendre, puisqu’il est étroitement lié à la cohésion. Pour savoir si une classe
respecte le SRP, il faut dire: « La classe X fait … » en étant le plus spécifique possible.
Si la phrase ci-dessus contient des « et » ou des « ou », alors votre classe a plus d’une
responsabilité. Par contre, il ne faut pas pousser le concept trop loin. Par exemple, une
classe qui formate le numéro de matricule d’un employé peut être un peu trop spécifique.
Open/Closed Principle (OCP)
Les entités d’un logiciel devraient être fermées aux modifications
mais ouvertes à l’extension.
L’OCP ou principe ouvert/fermé est beaucoup plus complexe que le premier principe.
Lorsqu’on dit qu’une classe est fermée aux modifications et ouverte à l’extension, il faut
bien interpréter le concept comme étant qu’il est souhaitable de créer une sous-classe
ou d’ajouter des membres pour lui apporter une modification d’état ou de comportement
que de modifier les membres existants. Donc, si vous devez modifier le corps d’une
méthode, sa signature ou encore le type d’une propriété d’une classe, vous avez de très
forte chance d’être en train de briser l’OCP.
Liskov Substitution Principle (LSP)
Si B et C sont des implémentations de A, alors B et C doivent pouvoir être interchangées sans affecter l’exécution du programme.
Le LSP ou principe de substitution de Liskov est très simple, mais son nom fait un peu
peur. En effet, il faut comprendre que les classes partageant une même classe parente
partagent aussi un état et/ou un comportement. Si un comportement est défini dans une
classe et qu’une autre en hérite, alors elle doit se conformer. Si ce comportement n’est
pas désiré dans la classe, alors le LSP n’est pas respecté.
Interface Segregation Principle (ISP)
L’appelant ne devrait pas connaître les méthodes qu’il n’a pas à utiliser.
L’ISP ou principe de ségrégation de l’interface est un autre principe un peu complexe. Le
couplage est un principe orienté-objet qui se quantifie en déterminant le nombre
d’interactions entre deux classes. On dit de deux classes qu’elles ont un couplage fort
lorsqu’elles s’utilisent. Afin de diminuer le couplage, il est possible de dépendre d’une
abstraction, cachant ainsi l’implémentation à l’appelant. Dans ce cas, on peut conclure
que l’ISP est lié avec le SRP par le fait que l’interface peut définir plusieurs concepts qui
ne sont pas nécessairement liés. Cependant, le problème avec l’ISP, c’est lorsqu’une
interface ou une classe abstraite devient trop volumineuse et expose trop d’information.
Dependency Inversion Principle (DIP)
Les modules d’une application devraient dépendre d’abstractions.
Le DIP ou principe d’inversion de dépendance nous dit que les dépendances d’une classe
ne devraient jamais être concrètes. Par conséquence, les classes deviennent fortement
couplées. Puisqu’elle ne doit pas connaître l’implémentation de ses dépendances, nous
pouvons nous assurer du respect de ce principe en inversant les dépendances, soit via
le constructeur, soit via les mutateurs
