[Que représente le “S” dans S.O.L.I.D ?] — The Duty of the Developer As A Professional #6

ENGLISH VERSION: [What is the letter “S” in S.O.L.I.D?] — The Duty of the Developer As A Professional #6

Hi les Re-Programmerz !

Toujours dans la continuité de notre série The Duty of The Developer as a Professional et comme promis dans notre article précédent La règle d’Or pour bien choisir son Architecture, nous allons voir ensemble et en détails les cinq principes S.O.L.I.D en commençant par la première lettre :

S représentant Single Responsability Principle (S.R.P) !

Jouons un petit jeu entre nous ! Avant que vous ne commenciez à lire notre article, j’aimerais que vous prenez un papier et un stylo et que vous écrivez dessus VOTRE définition de Single Responsability Principle, ensuite mettez cette feuille devant vous face cachée que vous ne relirez qu’à la fin de l’article. Vous pouvez écrire : “je ne sais pas” ou même laisser une page blanche, ce ne sera pas un soucis :)

Nous reviendrons plus tard sur ce que vous avez noté !

Bonne lecture !

Définition

“A class should have one and only one reason to change, and be responsible to one and only one role/actor.”

“Une classe ne doit avoir qu’une seule raison de changer et être responsable d’un seul rôle/acteur.”

— Robert Martin

Qu’est ce qu’un rôle/acteur ?

Avant toute chose, il faut dire que ce principe est très mal compris et induit énormément de confusion et d’ambiguïté dû à son nom Single Responsability.

En effet, nous associons directement Single Responsability à Single Task (une seule tâche) laissant penser que la S.R.P se définit de la manière suivante :

Une fonction/méthode doit faire qu’une seule chose, une seule tâche.

Cette définition correspond plus aux principes de Clean Code (exemple : une fonction/méthode ne doit pas dépasser 25 lignes, une ligne de code ne doit pas excéder 100 caractères, etc…) et non pas à la Single Responsability.

Une responsabilité est une série de fonctions qui servent un rôle/acteur. Robert Martin

Comment appliquer la S.R.P sur n’importe quelle fonctionnalité ? Et que nous apporte-t-elle ?

Prenons comme exemple une fonctionnalité X à développer :

Nous allons séparer notre code en quatre classes principales :

• Une classe View, qui représente le design de notre fonctionnalité.
• Une classe Presentation, qui concerne le formatage, le contenu (assez souvent traduit sur plusieurs langues), les couleurs ainsi que les styles de textes.
• Une classe BusinessLogic, qui correspond à la partie dite “Métier”, nous aurons ici tous ce qui est règles business liées à la fonctionnalité.
• Une classe Networking, quant à elle, va se charger de faire les appels réseaux vers différentes APIs.

Bien entendu, il existe bel et bien d’autres couches que nous n’avons pas citées (telles que la Navigation, la Database, etc…) mais pour l’exemple, nous allons nous concentrer sur ces quatre parties importantes.

Pour rappel, une équipe se compose, généralement, comme suit :

• Le Développeur (nous-mêmes 😎) est responsable de la conception technique et du développement sous forme de code de la fonctionnalité (dont les tests unitaires).
• Le Designer est responsable de la User Interface (UI), il remettra, sous forme de maquettes et prototypes, la fonctionnalité concernée.
• Le Content Strategist est responsable du contenu et de sa présentation (validant en amont la partie légale), des traductions dans les différentes langues souhaitées, du respect des règles liées à l’Accessibilité (définition : accès aux services de communication pour personnes à mobilité réduite).
• Le Product Owner (PO), est responsable de la fonctionnalité en elle-même, de sa conception fonctionnelle et d’en fournir toutes les règles métiers correspondantes.
• L’ équipe back-end, est responsable des Contrats d’interfaces des requêtes et des réponses fournis aux clients utilisant l’API (ces clients peuvent être des applications mobiles, sites web, un autre serveur, etc…)

Selon-vous, à quel rôle/acteur pourrions-nous associer la classe View ? …Nous sommes tous d’accord que la réponse est : le Designer !

En appliquant le même raisonnement sur les autres classes, nous obtenons le schéma suivant :

Grâce à la S.R.P, nous avons pu associer nos classes aux rôles/acteurs de l’équipe et nous pouvons à présent savoir où placer notre code pour assurer le bon fonctionnement de notre fonctionnalité par rapport aux différentes responsabilités !

Cependant, quand est-il de cette raison de changer ? 🤔

Une seule raison de changer ?

Maintenant que chacune de nos classes correspond à une seule et unique responsabilité et donc un seul et unique rôle/acteur, les seuls moments où nous serions amenés à changer ou modifier une de ces classes, serait suite à une demande de la part du rôle/acteur associé.

En effet :

• Si le Designer veut changer l’emplacement d’une image ou d’un texte nous changerons que la classe correspondante : View.
• Si le Product Owner veut changer une règle Business, nous toucherons que la classe correspondante : BusinessLogic (appelée aussi Interactor en Clean Architecture que nous verrons plus en détails dans un autre article 💪)
• Etc…

Les dangers du non-respect de la S.R.P

Prenons par exemple, une classe nommée Toto, ne respectant pas la S.R.P, qui contient les règles métiers ainsi que les appels réseaux.

Si l’équipe Back-end change le nom du noeud qui contient notre réponse dans le JSON qu’on reçoit pour notre fonctionnalité alors nous serons amenés à modifier la classe Toto.

Le danger est de casser involontairement les règles métiers du Product Owner, présentes dans la même classe Toto, en essayant de répondre aux changements de l’équipe Back-end…

Le Product Owner ne serait pas content si un changement venant d’un autre rôle/acteur vient casser ses règles métiers auxquelles il n’a demandé aucun changement…

Conclusion

La Single Responsabilité Principle nous permet de bien organiser notre code par rapport aux rôles/acteurs adéquats et de ne pas mélanger les responsabilités au sein d’une seule classe.

La raison de changer d’une classe ne se fera que par le biais de la responsabilité qui demande ce changement.

Nous voici donc à la fin de notre article, à présent reprenez la définition que vous avez notée, si vous avez joué le jeu :) maintenant pensez-vous avoir noté la bonne définition ?

Si vous avez bien compris ce principe à nos côtés, alors sachez que, vous venez de franchir une première grosse étape dans l’apprentissage de la fameuse Clean Architecture ! Un article dédié sera fait pour l’expliquer en détails une fois que nous aurons terminé de faire le tour ensemble des principes restants de S.O.L.I.D.

Prochain article la deuxième lettre de S.O.L.I.D le O représentant Open Close Principle !

Nous espérons que vous avez appris quelque chose aujourd’hui grâce à cet article ! Donnez-nous des clappes si vous l’avez apprécié et n’hésitez surtout pas à le partager au maximum s’il vous plaît ! 👊

Cet article a été co-écrit avec Mohammed HIMOUD et Linh NGUYEN.