Les principes SOLID :
Lorsque le développeur construit un logiciel suivant la mauvaise conception, le code peut devenir inflexible et plus fragile, de petites modifications du logiciel peuvent entraîner des bogues. Pour ces raisons, nous devrions suivre les principes SOLID.
SOLID est une norme de codage pour développer les logiciels de manière appropriée afin d’éviter une mauvaise conception , Lorsqu’il est appliqué correctement, votre code est plus extensible, logique et plus facile à lire.
Pour comprendre les principes de SOLID, vous devez connaître clairement l’utilisation de l’interface en programmation, dans cette article, Je vais essayer d’expliquer les principes SOLID de la manière la plus simple afin que les débutants puissent le comprendre facilement. Passons en revue chaque principe un par un:
S : Single Responsibility Principle :
Une classe ne devrait servir qu’à une seule préoccupation, Toutes les méthodes et propriétés doivent toutes viser le même objectif. Lorsqu’une classe a plusieurs objectifs ou responsabilités, elle devrait être transformée en une nouvelle classe.
👉 Voir l’exemple de code ci-joint :
- Pourquoi cette classe devrait-elle extraire des données de la base de données? Il est lié à la couche de persistance. La couche de persistance traite des données persistantes (stockage et récupération) d’un Répos de données qui n’est pas la responsabilité de cette classe.
- la méthode de mise en format « formatUserData() » n’est pas la responsabilité de cette classe. c’est mieux de la déléguer à une autre classe Utilitaire puisque nous pourrons avoir besoin de données de formats différents tels que XML, JSON, HTML, etc.
Donc, finalement, le code après refactoring sera décrit comme suit :
O : Open-closed Principle :
Les classes, modules ou fonctions … doivent être ouvertes pour l’extension, mais fermées pour la modification , elles peuvent être étendues sans modifier réellement le contenu de la classe que vous étendez. Si nous pouvions suivre suffisamment ce principe, il est possible de modifier ensuite le comportement de notre code sans jamais toucher à un morceau de code original .
Si par exemple nous voulons calculer la surface d’un triangle, nous devons ajouter une nouvelle méthode de calcul dans la classe Area . Cela ne respect pas le principe Open-Closed. Selon ce principe, nous ne pouvons pas modifier, mais on peut étendre . le block de code ci-dessous propose une solution qui permet d’ajouter une nouvelle classe sans modifier l’existant :
L : Liskov Substitution Principle
Le principe définit que les objets d’une super-classe doivent pouvoir être remplacés par des objets de ses sous-classes sans interrompre l’application.
Une méthode redéfinie d’une sous-classe doit accepter les mêmes valeurs d’entrée et de sortie que la méthode de la superclasse .
Mauvais exemple qui ne respecte pas le principe LSP :
L’aigle peut voler parce que c’est un oiseau, mais le pingouin un sous-type de oiseau qui ne peux pas voler , cela peut provoquer une interruption dans le code qu’on peut corriger de cette façon :
I : Interface Segregation Principle :
Un client ne doit pas être forcé d’implémenter une interface qu’il n’utilise pas.
Cette règle signifie que nous devrions casser nos interfaces dans de nombreuses plus petites pour mieux répondre aux besoins exacts de nos clients , les interfaces considérées comme contrat de services .
Un objet Robot doit définir une méthode « Sleep() » qui n’utilisera jamais , Cela viole la loi de la ségrégation des interfaces, qu’on peut corriger dans l’exemple ci-dessous :
D : Dependency Inversion Principle :
Les classes de haut niveau ne doivent pas dépendre des classes de bas niveau. Les deux devraient dépendre des abstractions.
Les abstractions ne doivent pas dépendre des détails. Les détails devraient dépendre des abstractions.
Ou simplement: Dépendre des abstractions, non pas sur des implémentations 😉 .
l’exemple ci-dessus contient un couplage fort entre la classe DataRepository et la classe Connnection, si nous voulons changer la connexion de MySQLConnection à NoSqlBConnection on doit modifier en dure l’injection du constructeur .
Dans l’autre exemple si-dessous , nous avons pas besoin de changer l’injection de constructeur dans la classe DataRepository, Parce qu’ici la classe dépend d’abstractions, pas de l’implémentation :
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live 😉
Auteur : yassine Abainou