A Nyitott/Zárt Elv (Open/Closed Principle, OCP) azt mondja, hogy a szoftverkomponenseknek nyitottnak kell lenniük a kiterjesztésre, de zártnak a módosításra: új viselkedést új kód hozzáadásával kellene bevezetni, nem a meglévő, tesztelt kód módosításával.
():
shape.kind == : * shape.r **
shape.kind == : shape.s **
shape.kind == : shape.w * shape.h
Minden új típus módosítást kényszerít egy növekvő if/elif láncolatban — törékeny és hibamágnes.
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)
A Triangle hozzáadása nulla módosítást igényel a total_area-ban — kiterjesztés módosítás nélkül.
→ polymorphism / inheritance → strategy pattern (inject behavior)
→ plugins / interfaces → higher-order functions / callbacks
Az OCP spekulatív módon alkalmazva túltervezéssé válik — olyan absztrakciók, amelyek olyan variációkra készültek, amely soha nem jön el. Ott alkalmazza, ahol a változás valószínű (a "három szabálya": absztrakt a variáció után ténylegesen megjelenik).
A harctéren tesztelt kód szerkesztése egy funkció hozzáadásához regresszió kockázatot hordoz abban, amit a kód már támogat; az OCP az új viselkedést új, elszigetelt egységekre korlátozza.
Ez az elv az kiterjeszthető keretrendszerek és bővítményi rendszerek mögött áll — és az LSP-tól függ, mivel a helyettesíthető altípusok teszik a "zárt" magot biztonságosnak maradni.