Dans le développement de logiciels, Conception orientée objet joue un rôle crucial lorsqu’il s’agit d’écrire du code flexible, évolutif, maintenable et réutilisable. L'utilisation de OOD présente de nombreux avantages, mais chaque développeur doit également connaître le principe SOLID pour une bonne conception orientée objet en programmation. Le principe SOLID a été introduit par Robert C. Martin, également connu sous le nom d'Oncle Bob, et constitue une norme de codage en programmation. Ce principe est l'acronyme des cinq principes indiqués ci-dessous :

• Principe de responsabilité unique (SRP)
• Principe ouvert/fermé
• Principe de substitution de Liskov (LSP)
• Principe de ségrégation d'interface (ISP)
• Principe d'inversion de dépendance (DIP)

Le principe SOLID aide à réduire les couplages serrés. Un couplage étroit signifie qu'un groupe de classes dépend fortement les unes des autres, ce que vous devez éviter dans votre code.

• À l’opposé du couplage serré se trouve le couplage lâche et votre code est considéré comme un bon code lorsqu’il comporte des classes faiblement couplées.
• Les classes faiblement couplées minimisent les modifications apportées à votre code et contribuent à rendre le code plus réutilisable, maintenable, flexible et stable. Discutons maintenant un par un de ces principes…

1. Principe de responsabilité unique

Ce principe stipule que Une classe ne devrait avoir qu’une seule raison de changer ce qui signifie que chaque classe devrait avoir une seule responsabilité, un seul travail ou un seul objectif. En d’autres termes, une classe ne devrait avoir qu’un seul travail ou objectif au sein du système logiciel.

aligner le texte CSS

Comprenons le principe de responsabilité unique à l'aide d'un exemple :

Imaginez un boulanger chargé de faire du pain. Le rôle du boulanger est de se concentrer sur la tâche de cuire le pain, en s’assurant que le pain est de haute qualité, correctement cuit et répond aux normes de la boulangerie.

java math.min

• Cependant, si le boulanger est également responsable de la gestion des stocks, de la commande des fournitures, du service aux clients et du nettoyage de la boulangerie, cela violerait le PRS.
• Chacune de ces tâches représente une responsabilité distincte, et en les combinant, la concentration et l’efficacité du boulanger dans la cuisson du pain pourraient être compromises.
• Pour adhérer au PÉR, la boulangerie pourrait attribuer différents rôles à différentes personnes ou équipes. Par exemple, il pourrait y avoir une personne ou une équipe distincte chargée de gérer les stocks, une autre de commander les fournitures, une autre de servir les clients et une autre de nettoyer la boulangerie.

2. Principe ouvert/fermé

Ce principe stipule que Les entités logicielles (classes, modules, fonctions, etc.) doivent être ouvertes à l'extension, mais fermées à la modification ce qui signifie que vous devriez pouvoir étendre le comportement d'une classe, sans le modifier.

Comprenons le principe ouvert/fermé à l'aide d'un exemple :

Imaginez que vous ayez une classe appeléePaymentProcessor>qui traite les paiements pour une boutique en ligne. Initialement, lePaymentProcessor>La classe ne prend en charge que le traitement des paiements par carte de crédit. Cependant, vous souhaitez étendre ses fonctionnalités pour prendre également en charge le traitement des paiements via PayPal.

Au lieu de modifier l'existantPaymentProcessor>classe pour ajouter le support PayPal, vous pouvez créer une nouvelle classe appeléePayPalPaymentProcessor>qui prolonge lePaymentProcessor>classe. De cette façon, lePaymentProcessor>la classe reste fermée pour modification mais ouverte pour extension, adhérant au principe ouvert-fermé

3. Le principe de substitution de Liskov

Le principe a été introduit par Barbara Liskov en 1987 et selon ce principe Les classes dérivées ou enfants doivent être substituables à leurs classes de base ou parents. . Ce principe garantit que toute classe enfant d'une classe parent doit être utilisable à la place de son parent sans aucun comportement inattendu.

Comprenons le principe de substitution de Liskov à l'aide d'un exemple :

L’un des exemples classiques de ce principe est un rectangle à quatre côtés. La hauteur d’un rectangle peut être n’importe quelle valeur et sa largeur peut être n’importe quelle valeur. Un carré est un rectangle de largeur et de hauteur égales. Nous pouvons donc dire que nous pouvons étendre les propriétés de la classe rectangle en classe carrée.

aléatoire c

Pour ce faire, vous devez échanger la classe enfant (carré) avec la classe parent (rectangle) pour correspondre à la définition d'un carré ayant quatre côtés égaux, mais une classe dérivée n'affecte pas le comportement de la classe parent, donc si vous le faites que cela violerait le principe de substitution de Liskov.

4. Principe de ségrégation des interfaces

Ce principe est le premier principe qui s'applique aux interfaces au lieu des classes dans SOLID et il est similaire au principe de responsabilité unique. Il déclare que ne forcer aucun client à implémenter une interface qui ne le concerne pas . Ici, votre objectif principal est de vous concentrer sur l’évitement des interfaces lourdes et de privilégier de nombreuses petites interfaces spécifiques au client. Vous devez préférer plusieurs interfaces client plutôt qu’une seule interface générale et chaque interface doit avoir une responsabilité spécifique.

Comprenons le principe de ségrégation des interfaces à l'aide d'un exemple :

Supposons que vous entrez dans un restaurant et que vous soyez purement végétarien. Le serveur de ce restaurant vous a donné la carte de menu qui comprend des plats végétariens, des plats non végétariens, des boissons et des friandises.

• Dans ce cas, en tant que client, vous devez disposer d’une carte de menu comprenant uniquement des plats végétariens, et non tout ce que vous ne mangez pas dans votre alimentation. Ici, le menu doit être différent pour différents types de clients.
• La carte de menu commune ou générale pour tous peut être divisée en plusieurs cartes au lieu d'une seule. L’utilisation de ce principe contribue à réduire les effets secondaires et la fréquence des changements requis.

5. Principe d'inversion de dépendance

Le principe d'inversion de dépendance (DIP) est un principe de conception orientée objet qui stipule que Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Les deux devraient dépendre d’abstractions . De plus, les abstractions ne devraient pas dépendre de détails. Les détails devraient dépendre des abstractions.

Linux changer le nom du répertoire

• En termes plus simples, le DIP suggère que les classes devraient s'appuyer sur des abstractions (par exemple, des interfaces ou des classes abstraites) plutôt que sur des implémentations concrètes.
• Cela permet un code plus flexible et découplé, ce qui facilite la modification des implémentations sans affecter les autres parties de la base de code.

Comprenons le principe d'inversion de dépendance à l'aide d'un exemple :

Dans une équipe de développement de logiciels, les développeurs dépendent d'un système de contrôle de version abstrait (par exemple, Git) pour gérer et suivre les modifications apportées à la base de code. Ils ne dépendent pas de détails spécifiques sur le fonctionnement interne de Git.

Cela permet aux développeurs de se concentrer sur l’écriture de code sans avoir besoin de comprendre les subtilités de la mise en œuvre du contrôle de version.