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 (janvier 2016).

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

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

• Portail de la programmation informatique