Que sont les principes SOLID dans la programmation orientée objets ?

Le terme SOLID dans le développement représente 5 principes importants qui respectent certaines règles dans la programmation orientée objet et particulièrement dans le monde du .NET. C'est un acronyme que je vais décrire lettre par lettre dans cet article et qui peut-être questionné lors d'un entretien d'embauche comme ce fut le cas pour moi en Nouvelle-Zélande à plusieurs reprises.

Le S correspond à "Single Responsibility" qui se traduit par une seule responsabilité. Ce principe implique que votre code au sein d'une classe ne doit avoir qu'une seule responsabilité, qu'un seul type de tâche à effectuer. Si vous prenez conscience que 2 tâches différentes sont effectuées, posez-vous la question de savoir si vous devez scinder votre classe en deux ou non.

Le O correspond à "Open / Close" qui se traduit par... Ouvrir / Fermer ! La raison de ce principe est très simple, votre classe doit-être ouverte à une extension/mise à jour, mais doit-être fermée pour toutes modifications. Cette méthode permet d'éviter la régression suite à l'ajout de nouvelles fonctionnalités. Bien sûr qu'il peut y avoir des cas ou la modification est indispensable comme la résolution d'un bug, etc. Mais ce principe invite à le faire le moins possible.

Le L correspond à "Liskov Substitution" qui se traduit par substitution de Liskov. Juste pour information complémentaire, Liskov, de son prénom Barbara est une informaticienne de renom (prix Turing, équivalent du Nobel) qui a évoqué ce principe au début des années 90. Ce principe stipule d'une manière simplifiée, qu'un objet S d'un sous type T doit pouvoir remplacer un objet de type T sans avoir de conséquences dans le comportement du programme. L'exemple concret le plus souvent utilisé pour évoquer ce principe est le rectangle ainsi que le carré. En effet, prenons le rectangle comme Type principal et le Carré comme sous type du rectangle (le Type carré est un rectangle particulier et donc potentiellement héritable du Type rectangle), la question est alors, le carré peut-il remplacer le rectangle dans le programme sans avoir de conséquences ? Eh bien non ! Si vous remplacez l'objet de type rectangle et que vous mettez un objet de type carré, avec quel coté du rectangle peut-on calculer l'air de cet objet vu que le carré ne possède qu'un seul coté, qu'une seule propriété, et que le type rectangle en possède deux ? Pour respecter ce principe, la technique consistera à créer une classe dont héritera le carré et le rectangle et par exemple de créer une méthode abstraite que chacune des figures implémentera afin de pouvoir calculer l'air.

Le I correspond à "Interface segregation" qui se traduit par ségrégation des interfaces. C'est une technique qui consiste à préférer la création de plusieurs petites interfaces qui concentre vraiment le domaine dans lequel elle a été produite plutôt qu'une seule qui contiendrait beaucoup trop de déclarations. Cela facilite beaucoup de choses comme les tests unitaires, une meilleure décomposition du code et donc une meilleure compréhension générale.

Le D correspond à "Dependency Inversion" qui se traduit par inversion des dépendances. Ce principe permet d'inverser les dépendances entre les modules de vos applications. Concrètement, si vous avec un projet avec du code métier (Business Layer - BL) et un projet qui s'occupe de la persistance de vos données (Data Access Layer - DAL ), généralement votre projet BL référence votre projet DAL. Et bien avec ce principe, c'est justement l'inverse qui va se produire, vous n'allez plus faire référence à DAL dans votre projet BL et vous allez créer une abstraction et c'est à partir de là qu'intervient ce que l'on appelle une injection de dépendance. Ceci à des avantages à plus d'un titre : Faciliter les tests unitaires, gérer vos objets d'une manière responsable, remplacer votre DAL par une autre (changement d'une base de données), etc.

Voilà, j'espère que cette courte explication va vous permettre d'y comprendre un peu plus et n'hésitez pas à approfondir notamment sur l'injection des dépendances qui est fondamentale 🙂