Principe de responsabilité unique
Cet article est une ébauche concernant l’informatique.
Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.
Cet article ne s'appuie pas, ou pas assez, sur des sources secondaires ou tertiaires ().
Pour améliorer la vérifiabilité de l'article ainsi que son intérêt encyclopédique, il est nécessaire, quand des sources primaires sont citées, de les associer à des analyses faites par des sources secondaires.
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[modifier | modifier le code]
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[modifier | modifier le code]
- 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[modifier | modifier le code]
- (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]
