O Open/Closed Principle (OCP) diz que entidades de software devem estar abertas para extensão mas fechadas para modificação: você deve adicionar novo comportamento adicionando novo código, não editando código existente e testado.
():
shape.kind == : * shape.r **
shape.kind == : shape.s **
shape.kind == : shape.w * shape.h
Cada novo tipo força uma mudança em uma crescente cadeia if/elif — frágil e um ímã para bugs.
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)
Adicionar Triangle requer zero edições a total_area — extensão sem modificação.
→ polymorphism / inheritance → strategy pattern (inject behavior)
→ plugins / interfaces → higher-order functions / callbacks
OCP feito especulativamente se torna over-engineering — abstrações construídas para variação que nunca chega. Aplique onde mudança é provável (a "regra de três": abstrair após a variação realmente aparecer).
Editar código testado em batalha para adicionar um recurso arrisca regressões em tudo que esse código já suporta; OCP confina novo comportamento a novas unidades isoladas.
É o princípio por trás de frameworks extensíveis e sistemas de plugins — e depende de LSP, já que subtipos substituíveis são o que torna o núcleo "fechado" seguro para deixar intocado.