Que signifie le principe ouvert-fermé pour le refactoring ?

  • FrançaisFrançais



  • Dans son livre de 1988, Construction de logiciels orientés objet, professeur Bertrand Meyer défini le Principe ouvert-fermé comme:

    « Un module sera dit ouvert s’il est encore disponible pour extension. Par exemple, il devrait être possible d’ajouter des champs aux structures de données qu’il contient ou de nouveaux éléments à l’ensemble des fonctions qu’il exécute.

    “Un module sera dit fermé s’il est disponible pour être utilisé par d’autres modules. Cela suppose que le module a reçu une description bien définie et stable (l’interface dans le sens de la dissimulation d’informations).”

    Une façon plus succincte de le dire serait :

    Les entités logicielles (classes, modules, fonctions, etc.) doivent être ouvertes pour extension, mais fermées pour modification.

    De même (et parallèlement aux découvertes de Meyer), Alistair Cockburn défini le Variante protégée schéma:

    “Identifiez les points de variation prévue et créez une interface stable autour d’eux.”

    Les deux traitent de la volatilité des logiciels. Lorsque, comme c’est toujours le cas, vous devez apporter des modifications à un module logiciel, les effets d’entraînement peuvent être désastreux. La cause première des effets d’entraînement désastreux est un couplage étroit, de sorte que le principe ouvert-fermé et le modèle de variation protégé nous enseignent comment découpler correctement divers modules, composants, fonctions, etc.

    Le principe ouvert-fermé empêche-t-il le refactoring ?

    Si un module (c’est-à-dire un bloc de code nommé) doit rester fermé à toute modification, cela signifie-t-il que vous n’êtes pas autorisé à le toucher une fois qu’il est déployé ? Et si oui, cela n’éliminerait-il pas toute possibilité de refactorisation ?

    Sans la possibilité de refactoriser le code, vous êtes obligé d’adopter le principe de finalité. Cela signifie que la refonte n’est pas autorisée (pourquoi les parties prenantes accepteraient-elles de vous payer pour travailler à nouveau sur quelque chose qu’elles ont déjà payé ?) Ceci est en totale contradiction avec la discipline du refactoring.

    Si vous êtes autorisé à étendre le code déployé mais pas à le modifier, êtes-vous condamné à nager pour toujours dans les rivières en cascade ? N’avoir qu’une seule chance de faire quoi que ce soit est une recette pour un désastre.

    Passons en revue l’approche pour résoudre cette énigme.

    Comment protéger les clients contre les changements indésirables

    Les clients (c’est-à-dire des modules ou des fonctions qui utilisent un bloc de code) utilisent certaines fonctionnalités en adhérant au protocole tel qu’il a été initialement mis en œuvre dans le composant ou le service. Cependant, à mesure que le composant ou le service change inévitablement, le « partenariat » d’origine entre le service ou le composant et divers clients se rompt. Les clients « découvrent » le changement par casse, ce qui est toujours une mauvaise surprise qui ruine souvent la confiance initiale.

    Les clients doivent être protégés de ces bris. La seule façon de le faire est d’introduire une couche d’abstraction entre les clients et le service ou le composant. Dans le jargon du génie logiciel, nous appelons cette couche d’abstraction une “interface” (ou une API).

    Les interfaces et les API masquent l’implémentation. Une fois que vous avez organisé la livraison d’un service via une interface ou une API, vous vous libérez des soucis liés à la modification du code d’implémentation. Peu importe à quel point vous modifiez la mise en œuvre du service, vos clients restent parfaitement inchangés.

    De cette façon, vous êtes de retour dans votre monde confortable d’itérations. Vous êtes maintenant totalement libre de refactoriser, de réorganiser le code et de continuer à le réorganiser à la recherche d’une solution plus optimale.

    La chose dans cet arrangement qui reste fermée pour modification est l’interface ou l’API. La volatilité d’une interface ou d’une API est ce qui menace de briser la confiance établie entre le service et ses clients. Les interfaces et les API doivent rester ouvertes pour extension. Et cette extension se produit dans les coulisses, en refactorisant et en ajoutant de nouvelles fonctionnalités tout en garantissant la non-volatilité du protocole destiné au public.

    Comment étendre les capacités des services

    Bien que les services restent non volatiles du point de vue du client, ils restent également ouverts aux entreprises lorsqu’il s’agit d’améliorer leurs capacités. Ce principe ouvert-fermé est mis en œuvre par refactoring.

    Par exemple, si le premier incrément du OrderPayment le service offre de simples capacités simples (par exemple, capable de traiter le total de la commande et de calculer la taxe de vente), le prochain incrément peut être ajouté en toute sécurité en respectant le principe ouvert-fermé. Sans rompre la poignée de main entre les clients et le OrderPayment service, vous pouvez refactoriser l’implémentation derrière le OrderPayment API en ajoutant de nouveaux blocs de code.

    Ainsi, le deuxième incrément pourrait contenir la possibilité de calculer les frais d’expédition. Et ainsi de suite, vous obtenez l’image ; vous accomplissez le modèle de variation protégé en observant le principe ouvert-fermé. Il s’agit de modéliser soigneusement les abstractions métier.

    Source

    N'oubliez pas de voter pour cet article !
    1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
    Loading...

    Laisser un commentaire

    Votre adresse e-mail ne sera pas publiée.