SOLID PATTERN
Cours présenté par Tarek Ayari
TAREK AYARI 1
PRINCIPES SOLID
Définition
-Solid est une abréviation pour les cinq premiers principes de la conception orientée objet.
-Ces principes, lorsqu'ils sont combinés ensemble, il est facile pour les développeurs de
créer des logiciels faciles à entretenir et à étendre.
-Ils sont aussi une partie du développement logiciel agile.
TAREK AYARI 2
PRINCIPES SOLID
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
TAREK AYARI 3
SRP : SINGLE RESPONSIBILITY PRINCIPLE
Le principe de responsabilité unique, est qu'une classe donnée ne doit avoir qu'une
seule responsabilité, et, par conséquent, qu'elle ne doit avoir qu'une seule raison de
changer.
Les avantages de cette approche sont les suivants :
• Diminution de la complexité du code
• Augmentation de la lisibilité de la classe
• Meilleure encapsulation, et meilleure cohésion, les responsabilités étant regroupées.
TAREK AYARI 4
SRP : SINGLE RESPONSIBILITY PRINCIPLE
TAREK AYARI 5
SRP : EXEMPLE CONCRET
ENONCE
CORRECTION
Document Document
Microsoft Word Microsoft Word
TAREK AYARI 6
OCP : OPEN/CLOSE PRINCIPLE
Une classe doit être ouverte à l'extension, mais fermée à la modification
• En effet, vous ne devez pas modifier le code courant quand une nouvelle
fonctionnalité doit être ajoutée- vous devriez plutôt être en mesure d'étendre les
types et mettre en œuvre la fonctionnalité.
• La conformité au principe Ouvert Fermé facilite la création d'applications qui sont
réutilisables et peuvent être maintenues facilement.
• Vous devriez être en mesure de représenter ce principe en utilisant des abstractions.
• Les dérivés qui sont créés à partir de cette abstraction sont clos pour modification
depuis l'abstraction est fixé. Cependant, vous pouvez étendre le comportement en
créant de nouveaux dérivés de l'abstraction qui a déjà été défini. TAREK AYARI 7
OCP : OPEN/CLOSE PRINCIPLE
ENONCE
CORRECTION
Document Document
Microsoft Word Microsoft Word
TAREK AYARI 8
LSP : LISKOV SUBSTITUTION PRINCIPLE
- il doit être possible de substituer une classe "parente" par l’une de ses classes
enfants
- Pour le mettre en pratique et le vérifier, il suffit de se demander si une sous classe
peut facilement remplacer la classe de base sans créer un problème.
TAREK AYARI 9
LSP : LISKOV SUBSTITUTION PRINCIPLE
TAREK AYARI 10
LSP : LISKOV SUBSTITUTION PRINCIPLE
En orienté objet, un rectangle est constitué de 2 attributs : « largeur » et « hauteur »
avec leurs « setter » et « getter ».
TAREK AYARI 11
LSP : LISKOV SUBSTITUTION PRINCIPLE
- Un carré, par contre, n’a qu’un
attribut : « coté », avec un setter
et un getter.
Comment l’objet Carre va-t-il
gérer les méthodes setter et
getter de rectangle ?
Les méthodes « set/getHauteur »
et « set/getLargeur » ne sont pas
relevantes ou pertinentes pour un
carré !
TAREK AYARI 12
LSP : LISKOV SUBSTITUTION PRINCIPLE
- La question est alors, le carré peut-il remplacer le rectangle dans le calcul de
surface ?
- Eh bien non !
- Si vous remplacez l'objet de type rectangle et que vous mettez un objet de
type carré, avec quel coté du rectangle peut-on calculer la surface de cet
objet vu que le carré ne possède qu'un seul coté, qu'une seule propriété, et
que le type rectangle en possède deux ?
- Ceci est une violation du principe de substitution de Liskov.
TAREK AYARI 13
LSP : LISKOV SUBSTITUTION PRINCIPLE
- Pour respecter ce principe, la
technique consistera à créer
une classe dont héritera le
carré et le rectangle et par
exemple de créer une méthode
abstraite que chacune des
figures implémentera afin de
pouvoir calculer la surface.
TAREK AYARI 14
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
• Créer des interfaces à grains fin qui sont spécifiques au client
• Le principe ISP indique que les clients ne devraient pas être contraints de mettre en
œuvre une interface qui contient des déclarations de membres ou opérations qu'ils
ne seraient pas besoin ou ne jamais utiliser. Ces interfaces sont connues comme
«gras» ou interfaces pollués
TAREK AYARI 15
ISP : INTERFACE SEGREGATION PRINCIPLE
TAREK AYARI 16
ISP : INTERFACE SEGREGATION PRINCIPLE
TAREK AYARI 17
DIP : DEPENDENCY INVERSION PRINCIPLE
• Il faut dépendre des abstractions, pas des implémentations
• Une caractéristique clé du DIP est la programmation d'abstraction pour que les
consommateurs puissent compter sur ces abstractions plutôt que leurs
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é
• le DIP réduit couplage entre différents morceaux de code.
TAREK AYARI 18
DIP : EXEMPLE CONCRET
TAREK AYARI 19
DIP : EXEMPLE CONCRET
TAREK AYARI 20
CONCLUSION
• 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 .
• La raison 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
TAREK AYARI 21