Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Fathi Bellahcene

.Net m'a tuer!

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 Sourire
  • 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 :

BAD_SRP

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:

GOOD_SRP

 

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/

Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
Posted: samedi 26 novembre 2011 22:51 par fathi

Commentaires

Pas de commentaires

Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01