S.O.L.I.D PAR LA PRATIQUE(2è partie)

INTRODUCTION

Après  le premier article qui nous a permis de planter le décore, nous voici en plein dans ce voyage pour comprendre les principes S. O . L . I . D par la pratique. Pour ceux qui n'ont pas encore lu le premier article il est accessible ici

SOMMAIRE

1- Que représente le "S"

2- Cas pratique

3- Conclusion

1- Que représente le "S"

Tout commence par là. C'est le premier des 5 principes. C'est certainement le plus simple à comprendre cela ne dit en rien que les autres ne sont pas facilement compréhensible. Mais en terme niveau de compréhension, on peut dire c'est le plus simple.

SRP ou principe de la responsabilité unique est le principe qui précise ce qui suit: 

Une classe doit avoir une et une seule raison de changer ou encore, une classe doit réaliser une et une seule tâche.

Pour faire une comparaison, on pourrait dire que ce principe est à l'orienté objet ce que le singleton est au patron de conception. J'espère qu'on se comprends 😀 

Ce principe ne se limite pas uniquement aux classes ou aux entités(ce que j'ai remarque d'ailleurs), il est aussi bien valable pour les entités que pour les méthodes. Ainsi que se soit des classe ou des méthodes, elles ne doivent pas cumuler plusieurs responsabilités.

Par exemple: Un bateau ne peut pas être une voiture. Un avion ne peut pas être un vélo. Un infirmier n'est pas un dentiste etc. Les exemple sont légions.

Prenons le dernier exemple: ce que le dentiste peut faire, l'infirmier ne peut pas le faire; ce qui est tout à fait normale n'est-ce pas? 😅

Rigolons un peut: Vous allez à l'hôpital pour un problème de dents. Une fois sur place, on vous dit que le chirurgien dentiste vient de partir et on  vous dit l'infirmier le remplace. Vous n'allez pas avoir peur ou vous poser des questions? 😆

Il y'a une question qu'il faut se poser pour savoir si sa classe ou sa méthode respecte le principe de la responsabilité unique c'est la suivante:

• Que FAIT ma classe/méthode?

La réponse doit être simplement, ma class/méthode fait ça rien d'autres. Mais si vous avez une réponse comme ceci: ma class/méthode fait X et Y alors sachez que vous n'avez pas respecter le principe de la responsabilité unique tel que préconisé.

De la même manière que ce principe à l'air facile à comprendre, il est aussi facile de ne pas les respecter. Soyez donc vigilant les gars 😏

Bon trop de bavardage, voyons un cas concret:

2- Cas pratique

Tous les cas pratiques seront en langage java(8/20).

Nous sommes dans une team scrum en tant que développeur. Le sprint en cours est la gestion des utilisateurs c'est-à-dire: le CRUD, gestion des profils etc. Conformément aux spécificités fonctionnelles, vous devez gérer la partie du CRUD.

Exemple de code(erroné)

Analysons le code ci-dessus.

Nous avons:

    - une class du domaine ou une entité qui a des attributs

   - Elle doit initialiser les attributs d'un utilisateur  

   - Elle a une méthode qui permet d'enregistrer un utilisateur dans la base de données

   - Elle a une autre méthode qui permet de désactiver un utilisateur

On doit se poser la fameuse question: QUE FAIT MA CLASS?

Ma class initialise les informations de l'utilisateur, elle enregistre un utilisateur dans la base de données et enfin elle permet de désactiver un utilisateur.

Ma classe à 3 responsabilités donc le premier principe vient d'être violé lamentablement.

Exemple correcte

Pour l'enregistrement dans la base de donnée: 
  - Créer une interface qui étend JpaRepository ou CrudRepository(selon vos besoins)
  - Créer une interface comme service qui liste les actions à réaliser notamment l'insertion dans la BD
  - Créer une class qui implémente cette interface dans laquelle vous faites appelle à la première interface du Repository par le principe de l'injection des dépendance.
  - Enfin, dans une autre class de préférence dans un Controller, injecter le dernier service et utiliser celui-ci pour insérer dans la BD notre utilisateur
Quant à la méthode qui désactive un utilisateur on peut suivre le même principe. Pour qu'elle ait de sens il faut ajouter un autre champ de type boolean dans notre entité. C'est ce champ que cette méthode ira mettre à jour quand elle est appelée. Vous pouvez mieux faire en utilisant spring security en étendant la classe à UserDetails(c'est juste une parenthèse).

3- Conclusion

Nous avons vu a travers ce petit exemple comment implémenter le principe de la responsabilité unique. Il ne faut jamais oublier celui-ci. Eviter au maximum de faire faire à notre classe ou à notre méthode plus que ce qu'elle doit faire. Cette manière de faire est le début de la réalisation d'un code touffus, mal organisé, difficile à comprendre et à maintenir et très très difficile voir même impossible à faire évoluer.

Posons-nous toujours la question que nous avons vu plus haut: que faire notre classe/méthode?

A la prochaine pour l'article du principe "O" ✋