Principe de responsabilité unique
En programmation orientée objet, Robert C. Martin exprime le principe de responsabilité unique comme suit : « une classe ne doit changer que pour une seule raison » (a class should have only one reason to change)[1] - [2].
Exemple
Prenons l'exemple d'un module qui compile et imprime un rapport. Imaginons que ce module peut changer pour deux raisons. D'abord, le contenu du rapport peut changer. Ensuite, le format du rapport peut changer. Ces deux choses changent pour des causes différentes ; l'une substantielle, et l'autre cosmétique. Le principe de responsabilité unique dit que ces deux aspects du problème ont deux responsabilités distinctes, et devraient donc être dans des classes ou des modules séparés. Ce serait une mauvaise conception de coupler ces deux choses dans une même classe.
La raison pour laquelle il est important de garder une classe axée sur une seule préoccupation est que cela rend la classe plus robuste. En continuant avec l'exemple précédent, s'il y a un changement dans le processus de compilation du rapport, il y a un plus grand danger que le code d'impression se casse si elle fait partie de la même classe.
La responsabilité est définie comme une tâche assignée à un acteur unique[2].
Voir aussi
- Chaîne de responsabilité
- Cohésion (informatique)
- Principe ouvert/fermé
- SOLID - le S dans SOLID représente le principe de responsabilité unique.
Notes et références
- (en) « Agile Software Development: Principles, Patterns, and Practices »
- Feltus C. « Aligning Access Rights to Governance Needs with the Responsibility MetaModel (ReMMo) in the Frame of Enterprise Architecture » () (lire en ligne) [PDF]