Principios SOLID
Los principios SOLID son cinco guías de diseño orientado a objetos que buscan que el código sea más comprensible, flexible y fácil de mantener. Fueron popularizados por Robert C. Martin y hoy forman parte del vocabulario común de cualquier desarrollador que trabaja con software de mediano o gran tamaño.
Aplicarlos no garantiza que el código sea perfecto, pero sí ayuda a detectar y evitar los problemas más frecuentes que aparecen cuando un sistema crece sin estructura.
¿Por qué importan estos principios?
El código que no respeta ningún principio de diseño tiende a convertirse en lo que muchos llaman "código espagueti": todo está mezclado, los cambios generan efectos inesperados y agregar funcionalidades nuevas se vuelve cada vez más difícil.
SOLID proporciona un vocabulario y una dirección para evitar ese camino. Cada principio ataca un problema concreto de diseño y juntos forman una base sólida para sistemas que necesitan evolucionar.
S — Single Responsibility Principle
Una clase debe tener una sola razón para cambiar.
Si una clase se ocupa de demasiadas cosas, cualquier cambio en una de ellas puede romper las demás. El principio de responsabilidad única dice que cada clase debería tener un único foco.
Por ejemplo, una clase que gestiona usuarios no debería encargarse también de enviar correos o generar reportes. Cada una de esas responsabilidades debería vivir en su propia clase.
Esto no significa que cada clase tenga un solo método. Significa que todos sus métodos deberían estar orientados al mismo propósito.
Beneficio principal: los cambios quedan localizados. Si necesitas modificar cómo se envían los correos, solo tocas la clase de correos, no la de usuarios.
O — Open/Closed Principle
Las entidades de software deben estar abiertas para extensión, pero cerradas para modificación.
Cuando necesitas agregar comportamiento nuevo, deberías poder hacerlo sin cambiar el código que ya funciona. La forma más común de lograrlo es mediante herencia, composición o interfaces.
Imagina un sistema de pagos. Si cada vez que agregas un método de pago nuevo tienes que editar la clase principal de procesamiento, estás violando este principio. En cambio, si defines una interfaz común y cada método de pago la implementa, agregar uno nuevo no toca el código existente.
Beneficio principal: reduce el riesgo de romper comportamiento ya probado al extender la funcionalidad.
L — Liskov Substitution Principle
Los objetos de una clase derivada deben poder sustituir a los de su clase base sin alterar el comportamiento esperado del programa.
Dicho de otra forma: si tienes código que funciona con una clase base, debería seguir funcionando igual si le pasas una subclase. Si no es así, la herencia está mal diseñada.
Un ejemplo clásico: si tienes una clase Rectángulo con métodos para cambiar ancho y alto, y creas una subclase Cuadrado que redefine esos métodos para mantener ambas dimensiones iguales, puedes romper código que asume que ancho y alto son independientes.
Beneficio principal: la herencia deja de ser una trampa. El comportamiento polimórfico se vuelve predecible.
I — Interface Segregation Principle
Los clientes no deben depender de interfaces que no usan.
Una interfaz con demasiados métodos obliga a las clases que la implementan a definir cosas que no necesitan. Es mejor tener varias interfaces pequeñas y específicas que una grande y genérica.
Si tienes una interfaz Animal con métodos caminar(), volar() y nadar(), una clase Perro tendría que implementar volar() aunque no tenga sentido. La solución es dividir la interfaz en partes más pequeñas: Caminante, Volador, Nadador, y que cada clase implemente solo lo que le corresponde.
Beneficio principal: las implementaciones no cargan con contratos que no cumplen.
D — Dependency Inversion Principle
Los módulos de alto nivel no deben depender de módulos de bajo nivel. Ambos deben depender de abstracciones.
Este principio invierte la dirección natural de dependencias. En vez de que la lógica de negocio dependa directamente de una base de datos o de un servicio externo, debe depender de una abstracción (interfaz o clase abstracta) que esos detalles implementen.
Esto permite cambiar la implementación concreta, por ejemplo pasar de PostgreSQL a MongoDB, sin tocar la lógica de negocio.
Beneficio principal: el núcleo de la aplicación queda aislado de los detalles técnicos y se vuelve mucho más fácil de probar y sustituir.
SOLID en conjunto
Aunque cada principio tiene valor por sí solo, funcionan mejor en conjunto. Aplicar solo el primero sin el último puede resultar en código que está bien separado pero que sigue siendo difícil de probar. Aplicar el cuarto sin el segundo puede llevar a interfaces bien segregadas que igual requieren modificaciones constantes.
La tabla siguiente resume el problema que resuelve cada uno:
| Principio | Problema que resuelve |
|---|---|
| Single Responsibility | Clases con demasiadas responsabilidades |
| Open/Closed | Modificaciones que rompen código funcional |
| Liskov Substitution | Herencia que genera comportamiento inesperado |
| Interface Segregation | Interfaces que obligan a implementar cosas innecesarias |
| Dependency Inversion | Lógica de negocio acoplada a detalles técnicos |
Cuándo y cómo aplicarlos
SOLID no es una lista de requisitos que hay que cumplir desde el primer commit. En proyectos pequeños o prototipos, aplicarlos de forma estricta puede añadir complejidad innecesaria.
Lo más práctico es usarlos como guía para detectar problemas cuando ya existen. Si una clase cambia cada vez que se toca cualquier parte del sistema, probablemente viola el primer principio. Si agregar un tipo nuevo requiere modificar múltiples clases existentes, posiblemente viola el segundo.
También es importante no sobreingeniear. Una interfaz innecesaria o una jerarquía de herencia artificialmente profunda pueden ser igual de problemáticas que el código desorganizado que intentas evitar.
Buenas prácticas para empezar
- Revisa clases grandes antes de añadir funcionalidad. Si tienen más de una responsabilidad clara, divídelas primero.
- Prefiere composición sobre herencia. Suele ser más flexible y menos propensa a violar Liskov.
- Diseña hacia interfaces. Las dependencias sobre abstracciones hacen el código más fácil de probar y cambiar.
- Crea interfaces pequeñas. Si una interfaz tiene más de cuatro o cinco métodos que no comparten contexto, consideras dividirla.
- Usa inyección de dependencias. Es la forma más práctica de aplicar el quinto principio sin complejidad excesiva.
- Escribe pruebas. Los tests revelan rápidamente cuando el código viola SOLID, porque se vuelven difíciles de escribir.
Conclusión
Los principios SOLID son una brújula, no una ley. Su propósito es ayudarte a tomar mejores decisiones de diseño cuando el código comienza a crecer o a complicarse.
Conocerlos y reconocer cuándo se están violando es ya una ventaja enorme. No necesitas aplicarlos de forma perfecta desde el primer día, pero sí conviene tenerlos presentes cuando diseñas nuevas clases, introduces dependencias o decides cómo extender el comportamiento existente.