Das Open/Closed Principle (OCP) besagt, dass Softwareentitäten offen für Erweiterungen, aber geschlossen für Modifikationen sein sollten: Sie sollten neues Verhalten durch Hinzufügen von neuem Code hinzufügen, nicht durch Bearbeiten von bestehendem, getestettem Code.
():
shape.kind == : * shape.r **
shape.kind == : shape.s **
shape.kind == : shape.w * shape.h
Jeder neue Typ erzwingt eine Änderung in einer wachsenden if/elif-Kette — zerbrechlich und ein Magnet für Fehler.
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)
Das Hinzufügen von Triangle erfordert null Bearbeitungen an total_area — Erweiterung ohne Modifikation.
→ polymorphism / inheritance → strategy pattern (inject behavior)
→ plugins / interfaces → higher-order functions / callbacks
Wenn OCP spekulativ angewendet wird, wird es zu Überengineering — Abstraktionen, die für Variationen entworfen wurden, die nie eintreffen. Wenden Sie es dort an, wo Änderung wahrscheinlich ist (die "Regel der drei": abstrahieren Sie, nachdem die Variation tatsächlich auftritt).
Bearbeitungen von gut getesteter Code zum Hinzufügen einer Funktion riskiert Regressionen in allem, was dieser Code bereits unterstützt; OCP beschränkt neues Verhalten auf neue, isolierte Einheiten.
Es ist das Prinzip hinter erweiterbaren Frameworks und Plugin-Systemen — und es hängt von LSP ab, da substituierbare Subtypen das sind, was den "geschlossenen" Kern sicher machen, unverändert zu bleiben.