Dans Meyer Travaux logiciel orienté objet (1988) , il définit le principe ouvert / fermé les suivants:
- Un module sera dit ouvert s'il est toujours 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 dite fermée si elle est disponible pour une utilisation par d'autres modules. Cela suppose que le module a reçu une description stable et bien définie (l'interface au sens de masquage des informations).
Il poursuit en disant:
Si vous rouvrez un module, vous devez également rouvrir tous ses clients pour les mettre à jour, car ils reposent sur l'ancienne version. … [Ce problème] se pose chaque fois qu'un module doit être étendu par une nouvelle fonction ou un nouvel élément de données, déclenchant des changements dans les clients directs et indirects. ... Avec les approches classiques de conception et de programmation, il n'y a aucun moyen d'écrire des modules à la fois ouverts et fermés.
La solution de Meyer à ce dilemme est: un module n'étendent la bibliothèque en modifiant les classes existantes; à la place, écrire un nouveau module qui sous-classe des classes existantes, et ont nouveaux clients dépendent de ce nouveau module.
Maintenant, en 1988, je suis Toy écrivais programmes (procédures) en Turbo Pascal et Blankenship de base, mon 21e siècle expérience professionnelle est sur la JVM, le CLR, en langages dynamiques, donc je ne sais pas ce que veut Meyer par "approches classiques de la conception et de la programmation".
Un de exemple concret de Meyer pourquoi modules clients doit être rouverte (un switch sur une liste qui compte désormais plus de membres, ce qui nécessite plus de cas) semble assez raisonnable, mais il ne justifie pas près de l'affirmation selon laquelle chaque fois que vous ajouter des fonctionnalités à une bibliothèque module, vous devez mettre à jour tous ses clients .
Y a-t-il une raison historique pour laquelle cette affirmation semblait évidente en 1988? Par exemple, l'ajout de fonctions ou de structures de données à une bibliothèque statique C a-t-il modifié la disposition de sorte que même avec des API rétrocompatibles, les clients devaient être recompilés? Ou Meyer parle-t-il vraiment d'un mécanisme pour appliquer la compatibilité descendante de l'API?