Open/Closed Principle (OCP) mówi, że jednostki oprogramowania powinny być otwarte na rozszerzenie, ale zamknięte na modyfikację: powinieneś dodawać nowe zachowanie poprzez dodawanie nowego kodu, a nie edytowanie istniejącego, przetestowanego kodu.
():
shape.kind == : * shape.r **
shape.kind == : shape.s **
shape.kind == : shape.w * shape.h
Każdy nowy typ wymusza zmianę w rosnącym łańcuchu if/elif — kruchy i magnes na błędy.
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)
Dodanie Triangle wymaga zerowych edycji w total_area — rozszerzenie bez modyfikacji.
→ polymorphism / inheritance → strategy pattern (inject behavior)
→ plugins / interfaces → higher-order functions / callbacks
OCP zrealizowany spekulacyjnie staje się nad-inżynieryą — abstrakcjami zbudowanymi dla zmian, które nigdy się nie pojawią. Stosuj go tam, gdzie zmiana jest prawdopodobna ("reguła trójki": abstrakcja po tym, jak zmiana faktycznie się pojawi).
Edytowanie przetestowanego w boju kodu w celu dodania funkcji ryzyka regresji w całym, co ten kod już obsługuje; OCP ogranicza nowe zachowanie do nowych, izolowanych jednostek.
To zasada stojąca za rozszerzalnymi frameworkami i systemami wtyczek — i zależy od LSP, ponieważ zamienialne podtypy to właśnie to, co czyni "zamkniętą" rdzeniową część bezpieczną, aby jej nie dotykać.