Votre product owner va vous adorer : le principe d’ouverture fermeture (SOLID 2/5)

La dernière fois, nous avons vu le SRP, le principe de responsabilité unique. Aujourd’hui, nous nous intéressons au O de SOLID, il s’agit du principe d’ouverture / fermeture, alias OCP.

Avec le SRP, nous avons appris à découpler les responsabilités, mais cela ne signifie pas totalement découpler 2 objets, 2 fonctions, 2 modules. Un code reste tout de même un ensemble cohérent et a besoin d’interagir. L’OCP ne supprime pas les interactions mais les rend plus robustes.

Le principe de l’OCP

A l’origine des principe SOLID, Robert C. Martin reprend l’OCP de Bertrand Meyer, présenté dans son ouvrage Object oriented software construction en 1988. Meyer décrit alors l’OCP de la façon suivante.

Open for extension, but closed for modification

Cela signifie que les entités qui composent le code (modules, classes, fonctions, etc.) doivent être ouvertes pour des ajouts mais pas pour la modification de code déjà existant. Du code ancien ne devrait pas être changé.

Comme je le disais avant, l’OCP affecte le couplage des entités, défini par les connaissances qu’ont chaque entité l’une de l’autre. L’idée est ici de réduire le couplage en réduisant les connaissances de chaque entité au strict minimum.

Montre-moi du code !

Je vous ai perdu ? Pas de panique, voici un exemple.

Dans cet exemple, le chat n’a que ses propriétés, le reste du travail est effectué dans la classe Main, que l’on suppose être la classe principale exécutée par le programme.

Mais attends, ça marche très bien, pourquoi changer ?

Très bonne question. Mettons désormais que l’on ait un chat et un chien. Le chien peut aboyer mais aussi grogner, on stocke ses cris dans un tableau de strings. Une mauvaise pratique serait d’effectuer la modification suivante.

Vous le sentez venir ? Et si je vous demande de m’ajouter la classe Rat, la classe Fourmi et la classe Serpent ? On devra rajouter à chaque fois une condition à la fonction Description avec la bonne façon de gérer la classe. Très rapidement, le code devient illisible et difficile à maintenir.

Appliquons l’ouverture / fermeture

Plutôt que de réaliser la description dans la classe Main, nous allons déplacer cette fonctionnalité dans chaque classe d’animal, voyez par vous-même.

La classe Chat est désormais responsable de se décrire elle-même, pareil pour la classe Chien. Nous en revenons donc à la définition de ce principe : la classe Main est fermée aux modifications – telle qu’écrite, elle n’a pas besoin d’être modifiée – mais ouverte aux extensions – il est parfaitement possible d’ajouter une classe Hamster sans rien modifier d’autre.

TL;DR

Une classe ne devrait pas savoir à savoir comment une autre est implémentée afin d’éviter les erreurs en cascade lors d’une modification. Chaque classe implémente ses fonctionnalités, que ce soit directement ou dans des classes annexes (cf. le principe de responsabilité unique) afin d’être « plug & play ».

Et surtout, ne manquez pas le prochain article de la série sur la substitution de Liskov !

Sources

>https://medium.com/@severinperez/maintainable-code-and-the-open-closed-principle-b088c737262

>https://code.tutsplus.com/tutorials/solid-part-2-the-openclosed-principle--net-36600

>https://hackernoon.com/why-the-open-closed-principle-is-the-one-you-need-to-know-but-dont-176f7e4416d