Un bon logiciel orienté objet est caractérisé entre autre par la qualité du design de ses briques de base, de l’interaction entre ses différentes briques logicielles, de sa capacité à auto-gérer ses dépendances, de son habileté à évoluer et de sa facilité de compréhension, d’utilisation, … .
Pour concevoir de tels logiciels (qui ne sont ni rigides, ni fragiles, ni immobiles et ni visqueux), plusieurs principes ont vu le jour depuis la naissance du paradigme orienté objet et se sont affinés au fur et à mesure des challenges aux quels a fait face cette révolution dans le domaine du génie logiciel, principes, qui aujourd’hui sont encore soit inconnus de la nouvelle vague de développeurs orientés objets, soit mal appliqués par certains vétérans du code.
Tout art, métier est guidé par des principes de bonnes pratiques. Dans le cadre de l’artisanat du logiciel et plus précisément dans le contexte des systèmes orientés objets, les principes de design sont aussi vieux que le paradigme lui même. Ces principes, tout comme les langages de programmation orienté objet ont su évolué avec le paradigme, ce qui donne et continuera à donner vie au concept. Dans ce billet, je vais donc vous parler des 11 principes de base du design objet et de la gestion des dépendances énoncés par Uncle Bob, dont les 5 premiers sont plus connus sous le nom de principes SOLID et sont appliqués à l’écriture du code des objets, tandis-que les 6 autres font plus référence à la ré-utilisabilité, à la cohésion et à la gestion des dépendances dans les différents packages du système logiciel.
Les principes SOLID
La famille des principes SOLID est à un artisan du logiciel ce que sont les fondations à un architecte de bâtiments. Ces principes visent à rendre un logiciel maintenable, testable et évolutifs. SOLID désigne les cinq principes suivant:
- S pour Single Responsibility Principle (SRP): Principe de Responsabilité Unique
- O pour Open Closed Principle (OCP): Principe d’Ouverture Fermeture
- L pour Liskov Substitution Principle (LSP): Principe de Substitution de Liskov
- I pour Interface Segregation Principle (ISP): Principe de Ségrégation des Interfaces
- D pour Dependency Inversion Principle (DIP): Principe d’inversion des dépendances
Le Principe de Responsabilité Unique (SRP)
Énoncé:
THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE.
Entendez simplement par là qu’une classe ne doit avoir qu’une et une seule raison de changer. Autrement dit, la définition de la responsabilité ici équivaut à une raison de changement. Ceci peut sembler superflu, mais si on revient aux racines de la POO, il est évident que son objectif est de permettre l’écriture de logiciels en conceptualisant le monde réel, or dans le monde réel tout objet à une seule responsabilité: un exemple parlant est celui du barillet qui est un objet, la gâche un autre objet, les deux composés forment une serrure de porte qui est un objet composé. Et c’est ça l’objectif du SRP, créer des objets spécialisés dans leur fonction, de tels sorte qu’un objet puisse être modifié, remplacé, testé sans affecter le fonctionnement du système. En d’autres termes, créer des systèmes inébranlables.
Maintenant jetons un coup d’œil sur cette classe basique Logger.java qui permet d’écrire des logs (Pour des raisons de goût, j’écris mes exemples en Java, mais ils restent valables pour tout langage orienté objet)
A première vue, cette classe semble correcte, car si les spécification étaient de stocker les logs dans une base de donnée MariaDB et de les afficher en même temps sur la console, elle fait largement son boulot. Toutefois, on voit clairement qu’on peut avoir plus d’une raison de modifier cette classe:
- Changement du format des messages dans la console et dans la base de donnée (Ajout du nom de la classe appelante, de la date et de l’heure par exemple)
- Changement du SGBD (Changement de MariaDB pour Cassandra par exemple)
En effet, imaginez une seconde que cette classe soit utiliser par d’autres applications (Classes) ayant des besoins différents, par exemple une d’entre elles souhaitant simplement afficher les logs dans la console, une autre souhaitant stocker les logs dans une base de données, une autre dans un fichier, …; le simple changement de cette classe Logger.java, devra entraîner l’adaptation, la ré-compilation, le test et le redéploiement de toutes les classes qui l’utilisent. La solution pour remédier à ce problème de couplage entre les responsabilité est de respecter le SRP en dédiant une classe générique pour la persistance des données, une autre pour l’affichage, … et la classe Logger sera simplement un objet composé (comme notre serrure). Pour les autres composants du système qui souhaitent utiliser le stockage dans la base de donnée, ils utiliseront uniquement la classe dédiée à ce travail, ainsi de suite.
Le Principe d’Ouverture Fermeture (OCP)
Originally published at kadary.me.
