Fathi Bellahcene

SRP: Single Responsibility Principle

Ce post fait partie d’une serie se proposant de présenter les principes SOLID. Vous  trouverez l’introducton ainsi que les liens vers les autres articles ici.

Définition Wikipédia:

In object-oriented programming, the single responsibility principle states that every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.

Définition de Robert C. Martin:

A class should have one, and only one, reason to change.

Selon Robert C. Martin, plusieurs responsabilités au sein d’une même classe sont couplées. car tout modification d’une responsabilité impacte la classe et donc toutes les responsabilités qui sont incluses dans cette même classe. En des termes plus simples, une classe doit gérer une responsabilité unique, une responsabilité doit être vu comme un regroupement de fonctionnalités ayant un sens fonctionnel commun.

Appliquer le principe de la responsabilité unique permet d’éviter les défauts de design, de bénéficier d’une meilleure lisibilité du code et d’une meilleure cohésion, d’abaisser le couplage et de garantir l’encapsulation de l’information.

Bien qu’il nous semble plein de bon sens et simple à comprendre, mon expérience ma montré que c’est l’un des principes les moins respecté surtout lorsque l’on maintient une application: combien de fois a t’on ajouté une méthode a une classe sans se demander si il n’est pas préférable d’en créer une nouvelle? ou encore à la fin d’un dev on se dit qu’au final ces deux classe, c’est mieux de les redécouper en trois…Le problème est (a mon sens) plus liée à un manque de recul par rapport au code lorsque l’on est en train de l’écrire plutôt qu’a un niveau de connaissance technique.

Pour bien appliquer ce principe j’ai quelques pistes:

• Avant l’implémentation : il faut au préalable faire une première phase d’analyse en définissant l’ensemble des méthodes nécessaires à la réalisation des fonctionnalités attendues. A ce stade, nous avons une liste de méthodes non organisées entre elles. A partir de cette liste, on va regrouper les méthodes qui répondent à un besoin commun au sein d’une même classe. Il ne faut pas hésiter à créer autant de classes que nécessaires, même si certaines méthodes se retrouvent seules.
• A la fin du développement : demander a quelqu’un de relire votre code pendant que vous relisez le sien
• Lorsque l’on souhaite faire évoluer le code: une nouvelle méthode correspondant à un besoin déjà existant sera rajoutée à la classe correspondante. Par contre, s’il s’agit d’un nouveau besoin on devra créer une nouvelle classe.

Une manière de détecter quelles sont les classes qui ne respectent pas ce principe est par exemple de contrôler le nombre de lignes de code et le nombre de méthodes pour une classe: un trop grand nombre de lignes de code et de méthodes indiquent très souvent un cas de non respect du principe SRP. Un nom de classe trop générique ou pas clair est aussi un signe que ce qui est implémenté dedans vise plusieurs responsabilité.

Exemple d’un design qui ne respecte pas le principe SRP: prenons le cas du pattern Active record appliquer à la gestion des données des utilisateurs d’un logiciel quelconque :

On a ici une classe qui à plusieurs responsabilités distinctes:

• stockage de l’information (nom, prenom, date de naissance,…)
• la persistance en base des informations (méthodes save/update)
• le calcul d’informations (est un utilisateur valide,calcul de l’age)

On va donc couper ca en trois classes distinctes, une par responsabilité…ce qui nous donne ca:

On se retrouve donc avec :

• Une classe (POCO) User pour le stockage et le transport des informations métiers.
• Une classe UserDataAccess qui a pour responsabilité la persistance de ces informations
• Une classe UserInfo qui pour un utilisateur donné vous renvoi les informations calculés liées : l’âge et si il est valide.

Ici, on pourrais se dire que l'âge et la validité répondent à un besoin fonctionnel différent, il est donc préférable au sens SRP de les mettre dans des classes différentes et c’et juste. Par contre, il faut savoir faire la part des choses et ne pas non plus tomber dans un excès qui va nous conduire à avoir trop de classes et donc de baisser la lisibilité. Il faut savoir rester pragmatique: oui on ne respecte pas SRP dans ce cas car on ne souhaite pas démultiplier les classes et parce que nos responsabilités sont “petites” (une seul méthodes). Par contre, si on ajoute une méthode liée à la validation…on n’hésitera pas a couper notre classe.

Vous trouverez les sources des exemples ici:http://solidincsharp.codeplex.com/