Qu’est-ce que les principes SOLID ?

Qu’est-ce que les principes SOLID ?

Introduction

Les principes SOLID est un ensemble de principes de conception populaire, utilisés dans le développement de logiciels orientés objet. SOLID est un acronyme qui représente cinq principes de conception clés :

[S] ingle Responsibility Principle – principe de responsabilité unique
[O] pen/Closed Principle – principe ouvert-fermé
[L] iskov Substitution Principle – principe de substitution de Liskov
[I] nterface Segregation Principle – principe de ségrégation d’interface
[D] ependency Inversion Principle – principe d’inversion de dépendance

Les 5 principes SOLID

Historique

Les principes SOLID ont été développés par Robert C. Martin dans un essai de 2000, « Design Principles and Design Patterns », bien que l’acronyme ait été inventé plus tard par Michael Feathers. Dans son essai, Martin a reconnu que le succès d’un logiciel changera et se développera. À mesure que cela change, cela devient de plus en plus complexe. Sans de bons principes de conception, Martin prévient que le logiciel devient rigide, fragile, immobile et visqueux. Le développement des principes SOLID sont conçu pour lutter contre ces modèles de conception problématiques.

Principe de responsabilité unique

Le principe de responsabilité unique – [Single Responsibility Principle] déclare qu’il ne devrait jamais y avoir plus d’une raison pour qu’une classe change. Cela signifie que vous devez concevoir vos classes de manière à ce que chacune ait un seul objectif. Cela ne signifie pas que chaque classe ne doit avoir qu’une seule méthode mais que tous les membres de la classe sont liés à la fonction principale de la classe.  Lorsqu’une classe a plusieurs responsabilités, celles-ci doivent être séparées en nouvelles classes.

Lorsqu’une classe a plusieurs responsabilités, la probabilité qu’elle doive être modifiée augmente. Chaque fois qu’une classe est modifiée, le risque d’introduire des bogues augmente. En se concentrant sur une seule responsabilité, ce risque est limité.

Principe ouvert-fermé

Le principe ouvert-fermé – [Open/Closed Principle] fait appel à des entités qui peuvent être largement adaptées mais qui restent également inchangées. Cela nous amène à créer des entités dupliquées avec un comportement spécialisé par polymorphisme.

Grâce au polymorphisme, nous pouvons étendre notre entité parente pour qu’elle réponde aux besoins de l’entité enfant tout en laissant le parent intact.

Notre entité parente servira de classe de base abstraite qui peut être réutilisée avec des spécialisations supplémentaires par héritage. Cependant, l’entité d’origine est verrouillée pour permettre au programme d’être à la fois ouvert et fermé.

L’avantage de ce principe est qu’il minimise le risque du programme lorsque vous ajoutez de nouvelles utilisations pour une entité. Au lieu de retravailler la classe de base pour l’adapter à une fonctionnalité de travail en cours, vous créez une classe dérivée distincte des classes actuellement présentes dans le programme. Nous pouvons ensuite travailler sur cette classe dérivée unique, confiants que les modifications que nous y apporterons n’affecteront ni le parent ni aucune autre classe dérivée.

Principe de substitution de Liskov

Le principe de substitution de Liskov – [Liskov Substitution Principle] est nommé d’après Barbara Liskov, et déclare que : les fonctions qui utilisent des pointeurs ou des références à des classes de base doivent pouvoir utiliser des objets de classes dérivées sans le savoir. Lorsque vous travaillez avec des langages tels que C #, cela équivaut au code qui utilise une classe de base doit pouvoir remplacer une sous-classe sans le savoir.

Si vous créez une classe avec une dépendance d’un type donné, vous devriez être en mesure de fournir un objet de ce type ou de l’une de ses sous-classes sans introduire de résultats inattendus et sans que la classe dépendante connaisse le type réel de la dépendance fournie. Si le type de la dépendance doit être vérifié pour que le comportement puisse être modifié en fonction du type, ou si des sous-types génèrent des règles inattendues ou des effets secondaires, le code peut devenir plus complexe, rigide et fragile.

Principe de séparation des interfaces

Le principe de ségrégation d’interface – [Interface Segregation Principle] exige que les classes ne puissent exécuter que des comportements utiles pour atteindre sa fonctionnalité finale. En d’autres termes, les classes n’incluent pas les comportements qu’elles n’utilisent pas.

Ceci est lié à notre premier principe SOLID, ces deux principes dépouillent une classe de toutes les variables, méthodes ou comportements qui ne contribuent pas directement à leur rôle. Les méthodes doivent contribuer à l’objectif final dans leur intégralité.

Principe d’inversion de dépendance

Le principe d’inversion de dépendance – [Dependency Inversion Principle] est la dernière des cinq règles. Le principe fait deux déclarations. 

  • Le premier est que les modules de haut niveau ne doivent pas dépendre de modules de bas niveau. Les deux devraient dépendre d’abstractions. 
  • La deuxième partie de la règle est que les abstractions ne doivent pas dépendre des détails. Les détails doivent dépendre d’abstractions.

Le principe d’inversion de dépendance concerne principalement le concept de superposition dans les applications, où les modules de niveau inférieur traitent des fonctions très détaillées et les modules de niveau supérieur utilisent des classes de niveau inférieur pour réaliser des tâches plus importantes. Le principe spécifie que là où des dépendances existent entre des classes, elles doivent être définies à l’aide d’abstractions, telles que des interfaces, plutôt qu’en référençant directement des classes. Cela réduit la fragilité causée par les changements dans les modules de bas niveau introduisant des bogues dans les couches supérieures.

Conclusion

Les principes SOLID sont un excellent moyen d’améliorer votre code et de faciliter les modifications. Il peut être difficile de tous les réaliser dans un seul programme si vous débutez, alors concentrez-vous d’abord sur un à la fois. Finalement, vous écrirez des programmes SOLID par habitude.

Cependant, SOLID n’est qu’une étape pour devenir un développeur orienté objet. Ensuite, vous devriez vous familiariser avec les quatre composants de la POO : Polymorphisme / Abstraction / Héritage / Encapsulation.

Finalement, j’espère que cet article vous aide à comprendre les principes S.O.L.I.D de point de vue général. Vos commentaires et critiques constructives sont toujours appréciés, Vous pouvez aussi lire l’article à-propos Algorithmes et Structures de données ! Que dois-je savoir ?.

Partagez !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *