Index des principes
Gestion des évolutions et des dépendances entre classes
|
Principe
d'ouverture/fermeture
Open-Closed Principle (OCP) |
"Un
module doit être ouvert aux extensions mais fermé aux modifications."
|
|
Principe
de substitution de Liskov
Liskov Substitution Principle (LSP) |
"Les
méthodes qui utilisent des objets d'une classe doivent pouvoir utiliser
des objets dérivés de cette classe sans même le savoir."
|
|
Principe
d'inversion des dépendances
Dependency Inversion Principle (DIP) |
"A.
Les modules de haut niveau ne doivent pas dépendre de modules de bas
niveau. Tous deux doivent dépendre d'abstractions."
"B. Les abstractions ne doivent pas dépendre de détails. Les détails doivent dépendre d'abstractions." |
|
Principe
de séparation des interfaces
Interface Segregation Principle (ISP) |
"Les
clients ne doivent pas être forcés de dépendre d'interfaces qu'ils n'utilisent
pas."
|
Organisation de l'application en modules
|
Principe
d'équivalence livraison/réutilisation |
"La
granularité en termes de réutilisation est le package. Seuls des packages
livrés sont susceptibles d'être réutilisés."
|
|
Principe
de réutilisation commune
Common Reuse Principle (CRP) |
"Réutiliser
une classe d'un package, c'est réutiliser le package entier."
|
|
Principe
de fermeture commune
Common Closure Principle (CCP) |
"Les
classes impactées par les mêmes changements doivent être
placées dans un même package."
|
Gestion de la stabilité de l'application
|
Principe
des dépendances acycliques
Acyclic Dependencies Principle (ADP) |
"Les
dépendances entre packages doivent former un graphe acyclique.
"
|
|
Principe
de relation dépendance/stabilité |
"Un package doit dépendre uniquement de packages plus stables que lui." |
|
Principe
de stabilité des abstractions
Stable Abstractions Principle (SAP) |
"Les packages les plus stables doivent être les plus abstraits. Les packages instables doivent être concrets. Le degré d'abstraction d'un package doit correspondre à son degré de stabilité." |
