El Open/Closed Principle (OCP) dice que las entidades de software deben estar abiertas para extensión pero cerradas para modificación: debe agregar nuevo comportamiento agregando código nuevo, no editando código existente y probado.
():
shape.kind == : * shape.r **
shape.kind == : shape.s **
shape.kind == : shape.w * shape.h
Cada nuevo tipo fuerza un cambio en una cadena if/elif creciente — frágil e imán de errores.
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)
Agregar Triangle requiere cero ediciones a total_area — extensión sin modificación.
→ polymorphism / inheritance → strategy pattern (inject behavior)
→ plugins / interfaces → higher-order functions / callbacks
OCP hecho especulativamente se convierte en sobre-ingeniería — abstracciones construidas para variación que nunca llega. Aplícalo donde el cambio es probable (la "regla de tres": abstrae después de que la variación realmente aparece).
Editar código bien probado para agregar una característica arriesga regresiones en todo lo que ese código ya soporta; OCP confina el nuevo comportamiento a unidades nuevas y aisladas.
Es el principio detrás de frameworks extensibles y sistemas de complementos — y depende de LSP, ya que los subtipos sustituibles son lo que hace que el núcleo "cerrado" sea seguro para dejarlo intacto.
Una biblioteca de preguntas de entrevista de IT con respuestas detalladas — de Junior a Senior.
Donar