En programmation orientée objet, Robert C. Martin exprime le principe de responsabilité unique comme suit : (a class should have only one reason to change). 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.
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
Catégorie:Programmation orientée objet