Kalicrunch la newsletter, je m'abonne
Actualités
coder proprement QA
Actualité Expertise

Concevoir une application logicielle SOLID, de qualité et évolutive ?

29 juillet 2020

Explications sur ces 5 principes fondamentaux pour un code propre, compréhensible, maintenable et facile à tester, quel que soit le langage de programmation.

SOLID est un acronyme qui décrit un ensemble de principes de conception orientée objet, rendu populaire par Robert C. Martin dans son livre Agile Software Development, Principles, Patterns and Pratice (2002).

  • S comme Single Responsibility Principle (PRS)
  • O comme Open/Closed Principle (OCP)
  • L comme Liskov Substitution Principle (LSP)
  • I comme Interface Segregation Principle (ISP)
  • D comme Dependency Inversion Principle (DIP)

S, le principe de responsabilité unique

Ce principe suppose qu’une classe ne doit avoir qu’une seule responsabilité, une seule fonction, un seul traitement ou affectée à une une tâche. Ainsi, seules les modifications apportées à une partie de la spécification du logiciel peuvent affecter la spécification de la classe. En effet, si votre classe a plusieurs responsabilités, elles sont liées entre elle et en modifier une, c’est prendre le risque d’affecter les autres. Par exemple, une classe peut avoir pour objet d’effectuer un paiement par contre cette même classe, ne peut pas traiter les abandons de paniers dans le e-commerce.

O, le principe d’ouverture et de fermeture

Ce principe suppose qu’une classe ou un module peut être étendu (extensible), mais non modifiable. Ainsi, tout comportement supplémentaire attendu doit être ajouté à une autre classe qui étend votre classe initiale au lieu de la modifier. Pour exemple, toujours en e-commerce, après avoir défini une catégorie de produits avec certaines caractéristiques, vous souhaitez à postériori rajouter dans ce catalogue un nouveau produit qui est proche mais qui a des caractéristiques en plus. La facilité serait de modifier la classe des produits… alors que vous devez étendre la classe en rajoutant les nouvelles caractéristiques avant d’ajouter le nouveau produit.

L, le principe de substitution de Liskov (LSP)

Ce principe suppose qu’une classe dérivée ou sous-classe doit pouvoir être substituée à sa classe de base. Ainsi, un utilisateur de la classe de base doit pouvoir continuer à travailler si on lui livre une classe dérivée à la place. Cela sous-entend qu’il faut être très vigilant dans la modification des valeurs des attributs de la classe de base ou qu’on souhaite l’étendre.

I, le principe de séparation des interfaces (ISP)

Ce principe suppose que les interfaces spécifiques aux clients sont meilleures qu’une interface à usage général. Ainsi, plutôt que de créer une interface qui répondrait à tous les services dont ont besoin des différents usagers, l’idée est de multiplier des interfaces uniques par chaque clients (qui a un rôle, une tache à faire ou un traitement à effectuer) en se concentrant sur les besoins fonctionnels.

D, le principe d’inversion des dépendances (DIP)

Ce principe suppose que le module de haut niveau ne doit pas dépendre du module de plus bas niveau, mais qu’ils doivent reposer sur des abstractions.

Pour aller plus loin

Coder proprement par Robert C. Martin avec plusieurs de cas

À lire également
Actualité
15 janvier 2021
Toute l’équipe Kalisoft vous souhaite une bonne année 2021 ! Tous nos meilleurs voeux de santé en premier lieu, de patience également car nul doute que 2021 va encore nous demander de faire preuve de résilience et voeux de bonheur avec l’espoir que nous allons bientôt pouvoir de nouveau partager des moments de convivialité ! Nous sommes(...)
Actualité
8 décembre 2020
Toute l’équipe de direction de Kalisoft ainsi que nos référents sur nos practices technologiques vous donnent rendez-vous à distance pour des sessions de recrutement. Vous souhaitez rejoindre les nombreux talents qui sont aujourd’hui en CDI en France Chez Kalisoft ? Vous souhaitez échanger, parler carrière en France et des différentes possibilités qui s’offrent à vous(...)
Actualité
18 novembre 2020
Quel plan de réduction de la dette technique de votre SI ? Où comment faire en sorte que votre SI ne bascule dans l’économie du jetable, incapable de s’engager dans les défis structurants de demain qui préserveront la vitalité et la longévité de votre entreprise. La dette technologique pourrait se résumer à la somme de(...)