Il Principio Open/Closed (OCP) dice che le entità software dovrebbero essere aperte per l'estensione ma chiuse per la modifica: dovresti aggiungere nuovo comportamento aggiungendo nuovo codice, non modificando codice esistente e testato.
():
shape.kind == : * shape.r **
shape.kind == : shape.s **
shape.kind == : shape.w * shape.h
Ogni nuovo tipo forza un cambio a una crescente catena if/elif — fragile e una calamita per i bug.
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)
Aggiungere Triangle richiede zero modifiche a total_area — estensione senza modifica.
→ polymorphism / inheritance → strategy pattern (inject behavior)
→ plugins / interfaces → higher-order functions / callbacks
OCP fatto speculativamente diventa over-engineering — astrazioni costruite per variazioni che non arrivano mai. Applicalo dove il cambiamento è probabile (la "regola del tre": astrarre dopo che la variazione effettivamente appare).
Modificare codice battle-tested per aggiungere una funzione rischia regressioni in tutto ciò che quel codice già supporta; OCP confina il nuovo comportamento a unità nuove e isolate.
È il principio dietro i framework estensibili e i sistemi plugin — e dipende dal LSP, poiché sottotipi sostituibili sono ciò che rende il nucleo "chiuso" sicuro da lasciare intatto.