Het Open/Closed Principle (OCP) zegt dat software-entiteiten open voor uitbreiding maar gesloten voor modificatie moeten zijn: je voegt nieuw gedrag toe door nieuwe code toe te voegen, niet door bestaande, geteste code aan te passen.
():
shape.kind == : * shape.r **
shape.kind == : shape.s **
shape.kind == : shape.w * shape.h
Elk nieuw type dwingt een wijziging in een groeiende if/elif-keten — fragiel en een magneet voor fouten.
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)
Het toevoegen van Triangle vereist geen wijzigingen in total_area — uitbreiding zonder modificatie.
→ polymorphism / inheritance → strategy pattern (inject behavior)
→ plugins / interfaces → higher-order functions / callbacks
OCP speculatief toegepast leidt tot over-engineering — abstracties gebouwd voor variatie die nooit komt. Pas het toe waar verandering waarschijnlijk is (de "regel van drie": abstraheer nadat de variatie daadwerkelijk verschijnt).
Het aanpassen van goed geteste code om een feature toe te voegen riskeert regressies in alles wat die code al ondersteunt; OCP beperkt nieuw gedrag tot nieuwe, geïsoleerde eenheden.
Het is het principe achter uitbreidbare frameworks en plugin-systemen — en het hangt af van LSP, omdat vervangbare subtypen wat de "gesloten" kern veilig ongewijzigd achterlaat.