Les principes SOLID démystifiés — Introduction

La création de logiciels complexes est à la fois exaltante et stimulante, mais c'est encore plus difficile et déprimant lors de la maintenance et de la mise à niveau d'un logiciel mal écrit.

La méthodologie dans laquelle nous écrivons un code excellent et bien structuré consiste à suivre et à adhérer à un ensemble de principes appelés les principes SOLID .

Les principes SOLID ont été introduits pour la première fois par l'informaticien Robert C. Martin dans son article publié en 2000.

Regardons l'acronyme SOLID :

(S) ingle Principe de Responsabilité ←

Une classe ne doit être responsable que d'un seul objectif, ce qui signifie qu'une classe ne doit avoir qu'un seul type de travail à effectuer, tel que (logique de base de données, logique de journalisation, etc.).

Principe (ouvert/fermé) ←

Une classe doit être ouverte pour extension et fermée pour modification, ce qui signifie qu'une classe existante doit être extensible sans avoir à être réécrite afin d'implémenter de nouvelles fonctionnalités.

(L) Iskov Principe de substitution ←

Les classes parentes doivent être facilement substituables avec leurs classes enfants, ce qui signifie que si la classe Rectangle est un sous-type de la classe Shape, nous devrions pouvoir remplacer Shape par Rectangle sans perturber le flux fonctionnel.

(I) nnterface Principe de Ségrégation ←

Les interfaces ne doivent pas forcer les classes à implémenter des fonctionnalités qu'elles ne prennent pas en charge, ce qui signifie que les interfaces plus grandes doivent être divisées en plus petites pour offrir un support.

(D) Principe d'inversion de dépendance ←

Les classes doivent dépendre de l'abstraction mais pas de la concrétion, ce qui signifie que les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Les deux doivent dépendre de l'abstraction.