SOLID son cinco principios de diseño para construir sistemas OOP mantenibles y flexibles. Cada uno aborda una causa común de código rígido y frágil.
SOLID son cinco principios de diseño para construir sistemas OOP mantenibles y flexibles. Cada uno aborda una causa común de código rígido y frágil.
| Letra | Principio | Significado en una línea |
|---|
| S | Single Responsibility | Una clase debe tener una razón para cambiar |
| O | Open/Closed | Abierto para extensión, cerrado para modificación |
| L | Liskov Substitution | Los subtipos deben ser utilizables donde se use el tipo base |
| I | Interface Segregation | Muchas interfaces pequeñas valen más que una interfaz grande |
| D | Dependency Inversion | Depender de abstracciones, no de clases concretas |
# Dependency Inversion: high-level code depends on an abstraction
class Notifier: # abstraction
def send(self, msg): ...
class EmailNotifier(Notifier):
def send(self, msg): print("email:", msg)
class OrderService:
def __init__(self, notifier: Notifier): # injected abstraction
self.notifier = notifier # not "new EmailNotifier()"
def place(self):
self.notifier.send("order placed") # works with ANY Notifier
OrderService no depende específicamente de correo electrónico — cámbialo a SMS o una doble de prueba sin tocarlo (D). Agregar un nuevo tipo de notifier no requiere cambio en OrderService (O).
SOLID es una guía, no una ley. Sobre-aplicarlo — una interfaz por clase, indirección en todas partes — produce "sopa de abstracción" que es más difícil de seguir que el problema que resolvió.
SOLID proporciona un lenguaje de diagnóstico compartido: los revisores pueden nombrar por qué una clase es difícil de cambiar ("esto viola SRP") en lugar de argumentar por gusto.
Aplicados con criterio, los principios reducen efectos en cascada — los cambios se mantienen locales, las nuevas características se extienden en lugar de reescribirse, y las pruebas pueden reemplazar falsificaciones por dependencias reales.