Los principios SOLID son cinco guías de diseño para crear clases más mantenibles y extensibles en programación orientada a objetos.
En la entrada anterior hablamos de cohesión y acoplamiento. Concluimos que nuestro objetivo como desarrolladores es lograr una alta cohesión y un bajo acoplamiento.
Vale, eso suena genial en la teoría. Ahora bien, ¿cómo lo conseguimos en la práctica? ¿Qué reglas debes seguir al escribir una clase para asegurar que no estás creando un monstruo?
Para eso usamos los principios SOLID. Si la programación orientada a objetos es la herramienta, SOLID nos ayuda a usarla sin hacernos daño con ella.
Si trabajas en aplicaciones que van a crecer y mantenerse en el tiempo, entender SOLID te va a ahorrar muchos dolores de cabeza.
¿Qué es SOLID?
SOLID es un acrónimo mnemotécnico que agrupa cinco principios básicos del diseño de software orientado a objetos.
Estos principios fueron recopilados por Robert C. Martin (el famoso “Uncle Bob”) a principios de los 2000, aunque el acrónimo en sí fue acuñado más tarde por Michael Feathers.
La premisa es sencilla: si aplicas estos principios con criterio, tu software será más fácil de entender, mantener y extender.
SOLID no son “leyes” inmutables como la gravedad. Son recomendaciones y principios que nos guían hacia un mejor diseño. A veces hay razones para romperlos, pero hay que saber muy bien por qué lo haces.
Los principios SOLID
Vamos a hacer un resumen rápido de cada uno. No te preocupes si alguno suena abstracto ahora, porque dedicaremos un artículo entero a cada principio con ejemplos de código.
| Letra | Principio | Nombre en inglés | Resumen rápido |
|---|---|---|---|
| S | Responsabilidad Única | Single Responsibility Principle (SRP) | Una clase debe tener una sola razón para cambiar. |
| O | Abierto / Cerrado | Open/Closed Principle (OCP) | El software debe estar abierto a extensión, pero cerrado a modificación. |
| L | Sustitución de Liskov | Liskov Substitution Principle (LSP) | Si una clase B hereda de A, deberíamos poder usar B en lugar de A sin romper nada. |
| I | Segregación de Interfaces | Interface Segregation Principle (ISP) | Es mejor tener muchas interfaces pequeñas y específicas que una interfaz gigante y general. |
| D | Inversión de Dependencias | Dependency Inversion Principle (DIP) | Depende de abstracciones, no de implementaciones concretas. |
¿Por qué necesitamos SOLID?
Para entender la solución, primero tenemos que entender el problema. Robert C. Martin define los síntomas de un “diseño podrido” (Bad Design). Seguro que te suenan de algún proyecto en el que has sufrido:
- Rigidez: El sistema es difícil de cambiar porque cada cambio afecta a demasiadas partes.
- Fragilidad: Al cambiar algo, el sistema se rompe en sitios que aparentemente no tenían relación.
- Inmovilidad: Es difícil reutilizar partes del código en otros proyectos porque tiene demasiadas dependencias (el problema de “quería el plátano pero me traje el gorila y la selva entera”).
- Viscosidad: Es más fácil hacer las cosas mal (hacks) que hacerlas bien respetando el diseño.
Los principios SOLID atacan directamente estos síntomas.
Beneficios directos
Al aplicar SOLID, obtenemos:
- Mantenibilidad: El código es más limpio y fácil de leer. Sabemos dónde buscar cuando algo falla.
- Escalabilidad: Podemos añadir nuevas funcionalidades sin tener que reescribir la mitad del código existente (gracias al principio OCP, por ejemplo).
- Testabilidad: Es, posiblemente, el mayor beneficio inmediato. El código desacoplado es mucho más fácil de probar con pruebas unitarias.
¿Es SOLID la solución a todo?
SOLID no es la solución a todo. Aplicarlo requiere más esfuerzo al principio: escribiremos más clases, más interfaces y más archivos. Para un script rápido de 50 líneas, aplicar SOLID es sobreingeniería.
El arte del diseño de software está en saber cuándo aplicar estos principios. No intentes aplicar SOLID a todo desde el minuto uno. Refactoriza hacia SOLID a medida que el sistema crece y muestra “dolor”.
Sin embargo, en una aplicación que pretenda durar en el tiempo y ser mantenida por un equipo, SOLID es una referencia muy útil.
