Definición: SOLID es un acrónimo que representa cinco principios de diseño de software orientado a objetos. Cuando se aplican correctamente, estos principios hacen que el código sea más fácil de entender, mantener y extender.
— Fuente: NERVICO, Consultoría de Desarrollo de Software
Qué es SOLID
SOLID fue introducido por Robert C. Martin ("Uncle Bob") y se ha convertido en uno de los pilares fundamentales del desarrollo de software profesional. No son reglas rígidas, sino guías que ayudan a tomar mejores decisiones de diseño.
Cada letra representa un principio diferente. Juntos, forman un marco para escribir código que no se rompe cuando crece.
S - Single Responsibility Principle (SRP)
Principio de Responsabilidad Única
"Una clase debe tener una única razón para cambiar."
Cada módulo, clase o función debe hacer una sola cosa bien. Si tienes una clase que gestiona usuarios Y envía emails Y genera reportes, tienes tres razones para cambiarla. Divídela.
Señales de violación:
- La clase tiene demasiados métodos públicos
- Es difícil nombrar la clase sin usar "y" o "o"
- Cambios en un área afectan a otras no relacionadas
O - Open/Closed Principle (OCP)
Principio Abierto/Cerrado
"Las entidades deben estar abiertas para extensión, cerradas para modificación."
Deberías poder añadir nuevas funcionalidades sin modificar código existente. Esto se logra mediante abstracciones, interfaces y composición.
Ejemplo práctico:
En lugar de un switch con casos para cada tipo de pago (tarjeta, PayPal, Bitcoin), define una interfaz MetodoPago y crea una clase por cada tipo. Añadir un nuevo método de pago no requiere tocar el código existente.
L - Liskov Substitution Principle (LSP)
Principio de Sustitución de Liskov
"Los objetos de una clase derivada deben poder sustituir a los de la clase base sin alterar el comportamiento correcto del programa."
Si tienes una clase Ave con un método volar(), y creas Pinguino que hereda de Ave... tienes un problema. El pingüino no puede volar. El diseño está mal.
La solución:
Repensar la jerarquía. Quizás Ave no debería tener volar(), o necesitas una interfaz Volador separada.
I - Interface Segregation Principle (ISP)
Principio de Segregación de Interfaces
"Los clientes no deben verse forzados a depender de interfaces que no usan."
Es mejor tener muchas interfaces específicas que una interfaz general que lo incluye todo. Si una clase implementa una interfaz, debería usar TODOS sus métodos.
Ejemplo:
Una interfaz Trabajador con trabajar(), comer() y dormir() obliga a que un robot implemente comer() y dormir(). Mejor separar en interfaces más pequeñas.
D - Dependency Inversion Principle (DIP)
Principio de Inversión de Dependencias
"Depende de abstracciones, no de concreciones."
Los módulos de alto nivel no deben depender de módulos de bajo nivel. Ambos deben depender de abstracciones. Esto permite cambiar implementaciones sin tocar el código que las usa.
En la práctica:
En lugar de que tu ServicioUsuarios cree directamente una instancia de MySQLDatabase, debe recibir una interfaz Database. Así puedes cambiar a PostgreSQL o a una base de datos en memoria para tests.
Por Qué SOLID Importa
- Código mantenible: Cambios localizados, sin efectos colaterales inesperados.
- Testeable: Componentes aislados que se pueden probar unitariamente.
- Extensible: Añadir funcionalidad sin romper lo existente.
- Comprensible: Cada pieza tiene un propósito claro.
- Reutilizable: Componentes bien diseñados se pueden usar en otros contextos.
Cuándo NO Aplicar SOLID (con cuidado)
SOLID puede llevar a sobre-ingeniería si se aplica dogmáticamente. Un script de 50 líneas no necesita cinco niveles de abstracción.
Usa SOLID cuando el código va a crecer, cuando trabaja un equipo, cuando necesitas tests, cuando el proyecto tiene larga vida. No lo uses para complicar código simple.