Single Responsibility Principle : votre code va enfin respirer
Imaginez un restaurant où le serveur cuisine, accueille, nettoie et fait la vaisselle. C'est le chaos total. Votre code, c'est pareil : chaque classe doit avoir son rôle, comme dans un restaurant 4 étoiles.
C'est le Single Responsibility Principle (SRP). Ce principe fait partie des principes SOLID, un ensemble de règles qui transforment un code brouillon, où tout est mélangé, en code propre, optimisé et facilement maintenable.
Pourquoi le SRP est important
Maintenabilité : chaque classe a un rôle clair et précis.
Testabilité : le code est plus simple à tester.
Réutilisabilité : les composants s'intègrent facilement ailleurs.
Découplage : les changements sont localisés et moins risqués.
Lisibilité : le code devient plus clair et organisé.
L'exemple : le UserService fourre-tout
Prenons une classe UserService typique qui fait tout : validation des données, gestion des mots de passe, interactions avec la base de données, et envoi d'emails. Un fourre-tout, quoi.
Avec le SRP, on découpe ses responsabilités :
UserValidator: vérifie la cohérence des données ;PasswordManager: gère le hachage et la sécurité des mots de passe ;UserRepository: gère les interactions avec la base de données ;EmailService: envoi et gestion des emails.
Résultat ? Un UserService qui orchestre ces composants, et ne fait pas tout lui-même.
Dans la vraie vie
Il y a encore énormément de projets avec des services de milliers de lignes qui gèrent tout et n'importe quoi. À chaque fois, je repense à cette phrase : « Just because you can doesn't mean you should. »
À retenir : un service qui fait tout ne fait rien bien.
Cet article est tiré d'une de mes publications LinkedIn : rejoignez la discussion ↗