Le Principe Ouvert/Fermé (Open/Closed Principle, OCP) stipule que les entités logicielles doivent être ouvertes à l'extension mais fermées à la modification : vous devez ajouter un nouveau comportement en ajoutant du nouveau code, non en modifiant du code existant et testé.
():
shape.kind == : * shape.r **
shape.kind == : shape.s **
shape.kind == : shape.w * shape.h
Chaque nouveau type force une modification à une chaîne if/elif croissante — fragile et un aimant à bugs.
from abc import ABC, abstractmethod
class Shape(ABC):
@abstractmethod
def area(self): ...
class Circle(Shape):
def __init__(self, r): self.r = r
def area(self): return 3.14159 * self.r ** 2
class Triangle(Shape): # NEW behavior = NEW class
def __init__(self, b, h): self.b, self.h = b, h
def area(self): return 0.5 * self.b * self.h
def total_area(shapes): # never changes again
return sum(s.area() for s in shapes)
Ajouter Triangle nécessite zéro modifications à total_area — extension sans modification.
→ polymorphism / inheritance → strategy pattern (inject behavior)
→ plugins / interfaces → higher-order functions / callbacks
L'OCP fait de manière spéculative devient sur-ingénierie — des abstractions construites pour une variation qui n'arrive jamais. Appliquez-le où le changement est probable (la "règle des trois" : abstraire après que la variation apparaît réellement).
Modifier du code éprouvé au combat pour ajouter une fonctionnalité risque des régressions dans tout ce que ce code supporte déjà ; l'OCP confine un nouveau comportement à des unités nouvelles et isolées.
C'est le principe derrière les frameworks extensibles et les systèmes de plugins — et il dépend du LSP, car les sous-types substituables sont ce qui rend le noyau "fermé" sûr de rester intact.