Thread by @DandreaWilliam

👨‍💻 Le framework ultime pour écrire du code maintenable et évolutif.

Découvre les principes #SOLID dans ce thread 🧱

⤵️⤵️⤵️⤵️⤵️⤵️⤵️⤵️

Le principe #SOLID est un ensemble de règles pour écrire du code maintenable, évolutif et robuste. Il est enseigné dans beaucoup d'écoles, et pour cause, si vous voulez un projet orienté objet propre, vous devrez appliquer ces principes !

1️⃣ | Principe - Single Responsibility principle

Le S représente le Single Responsibility Principle, qui stipule qu'une classe ne devrait avoir qu'une seule responsabilité.

1️⃣ | Exemple

Dans une application e-commerce, une classe qui s'occupe des commandes ne devrait pas également gérer les paiements. Il vaut mieux séparer ces responsabilités en deux classes distinctes.

2️⃣ | Principe - Open Closed principle

Le O représente le principe Open-Closed, qui dit qu'une classe devrait être ouverte à l'extension, mais fermée à la modification. En gros, c'est ok d'ajouter de nouvelles fonctionnalités, mais on ne touche pas au code existant.

2️⃣ | Exemple

Dans le cas d'un moteur de recherche, plutôt que de modifier la fonction de recherche existante pour ajouter de nouvelles fonctionnalités, on peut créer de nouvelles classes pour étendre les fonctionnalités de recherche.

3️⃣ | Principe - Liskov substitution principle

Le L représente le principe de substitution de Liskov, qui stipule qu'une classe dérivée devrait être substituable à sa classe de base sans altérer le comportement du programme.

Ok, celle-là est compliquée, voyons un exemple

3️⃣ | Exemple

Prenons une application orienté objet basique, autour des animaux. Si une classe Chien hérite de la classe Animal, elle devrait pouvoir être substituée à la place de la classe Animal sans altérer le comportement du code.

4️⃣ | Principe - Interface Segregation Principle

Le I représente le principe d'interface de ségrégation, qui dit qu'une classe ne devrait pas être forcée de dépendre d'interfaces dont elle n'a pas besoin.

4️⃣ | Exemple

Si on a une classe qui envoie des emails, si elle utilise des méthodes pour envoyer et enregistrer des emails, mais qu'elle n'a besoin que de la méthode d'envoi, il vaut mieux séparer ces méthodes en deux interfaces distinctes.

5️⃣ | Principe - Dependency Inversion Principle

Le D représente le principe de dépendance inversion, qui stipule que les modules de haut niveau ne devraient pas dépendre de modules de bas niveau, mais plutôt d'abstractions.

5️⃣ | Exemple

Dans une application de facturation, plutôt que d'avoir un module de facturation qui dépend directement de crédit mutuel, il vaut mieux utiliser une abstraction telle qu'une interface pour pouvoir changer rapidement de crédit mutuel à PayPal en cas de soucis.

🔚 CONCLUSION

Ces principes sont relativement durs à assimiler au début, mais toujours les avoirs en tête permet vraiment de faire la différence entre du code propre et du code sale, et les appliquer vous fera gagner beaucoup de temps sur le long terme

La différence entre les bons développeurs et les mauvais réside dans la rigueur que ceux-ci appliquent à leur code, et je peux vous garantir que sur des gros projets, cela fait une différence !

J'ai essayé d'être synthétique dans ce thread, mais si vous voulez, je peux faire un thread par principe, en les détaillants vraiment en profondeur, avec des exemples, etc ...

En espérant que ce thread vous aura plus, je vous retrouve demain pour le prochain thread du challenge d'un thread par jour

KISS ❤️