Una exploración profunda y crítica desde mi experiencia
En este artículo, ofrezco una reflexión profunda y crítica sobre los principios SOLID desde mi propia experiencia como profesional del software. Cuestiono su base teórica, originalidad y la manera en que han sido difundidos. A lo largo de la exposición, contextualizo SOLID en la historia del diseño orientado a objetos, explorando enfoques más completos y rigurosos que pueden servir mejor al desarrollo de arquitecturas sostenibles y efectivas.
De la admiración al cuestionamiento
Desde que comencé mi trayectoria en el desarrollo de software, los principios SOLID han aparecido constantemente como el estándar dorado del diseño orientado a objetos. Fueron popularizados por Robert C. Martin, conocido ampliamente como “Tío Bob”, a través de libros influyentes como Clean Code, Clean Coder y Clean Architecture. Inicialmente, como muchos, valoré estas ideas por su claridad y simplicidad aparente.
Sin embargo, con el tiempo, mi admiración dio paso a un cuestionamiento cada vez más profundo. Observaba cómo estos principios se habían convertido casi en un dogma incuestionable, una fórmula repetida sin una verdadera comprensión de su origen o fundamentos. Este artículo surge precisamente de esa inquietud y pretende llevar al lector más allá del acrónimo, invitándolo a cuestionar, entender y expandir sus conocimientos.
Los principios SOLID nacieron en los años 90, fruto de las experiencias personales y publicaciones de Robert C. Martin en revistas especializadas de C++. Con el advenimiento del Manifiesto Ágil en 2001, estas ideas encontraron terreno fértil y crecieron rápidamente en popularidad gracias a la hábil narrativa de Martin, cuya fuerza residía en comunicar de manera sencilla y emotiva conceptos técnicos complejos.
No obstante, esta simplificación se convirtió en un arma de doble filo. El rigor técnico que había caracterizado a grandes referentes del diseño modular, como Tom DeMarco, Page-Jones, Grady Booch o Ivar Jacobson, quedó desplazado por un discurso emocionalmente atractivo pero superficial. Mi crítica no se dirige hacia la utilidad de las ideas, sino hacia cómo esta forma simplificada de divulgarlas afectó negativamente a la calidad del conocimiento en nuestra profesión.
Originalidad y exhaustividad en cuestión
Mi exploración crítica sobre SOLID me llevó a concluir que estos principios no eran precisamente innovadores, sino que reempaquetaban conceptos establecidos desde mucho antes:
- Single Responsibility (S): Aunque se presenta como un principio, es esencialmente una consecuencia del conocido concepto de cohesión, profundamente desarrollado por DeMarco y Page-Jones. Presentarlo como “una razón para cambiar” simplifica en exceso una noción más rica y compleja.
- Open/Closed (O): Originalmente formulado por Bertrand Meyer, este principio ya era ampliamente reconocido y aplicado antes del surgimiento de SOLID, sin necesidad de una reinvención.
- Liskov Substitution (L): Un principio formal propuesto por Barbara Liskov, que gozaba de reconocimiento pleno en la comunidad académica mucho antes de ser integrado en SOLID.
- Interface Segregation (I): Surge naturalmente al aplicar Open/Closed y Liskov, lo que personalmente considero insuficiente para clasificarlo como un principio fundamental independiente.
- Dependency Inversion (D): Más complejo y debatible aún, es en realidad una derivación lógica de los principios Open/Closed y Liskov, careciendo de autonomía conceptual suficiente para sostenerse por sí mismo.
Al presentar estos cinco conceptos como principios equivalentes, se genera una percepción distorsionada que afecta negativamente la enseñanza y comprensión del diseño orientado a objetos.
“Clean” Architecture y el riesgo del simplismo
Cuando exploré por primera vez Clean Code y Clean Architecture, aprecié inicialmente la claridad en la expresión de ciertos conceptos. Sin embargo, al profundizar en estos textos desde un enfoque más crítico, noté con preocupación cómo simplificaban problemas altamente complejos en recetas aparentemente universales.
Mensajes del tipo “con SOLID ya sabes diseñar” o “aprende pruebas con un solo capítulo” generan una falsa sensación de competencia técnica. Estos libros sacrifican el análisis profundo y la riqueza histórica del diseño de software a favor de una narrativa simplista centrada en la figura del “programador virtuoso”. Esto, lejos de estimular la curiosidad intelectual, la limita, generando desarrolladores con conocimientos superficiales.
Alternativas sólidas al enfoque SOLID
Mi formación y experiencia me permitieron descubrir enfoques mucho más sólidos y completos que SOLID. Por ejemplo, la metodología Rational, propuesta por Booch y Jacobson, ofrece marcos de análisis y diseño altamente desarrollados que han probado su eficacia en grandes proyectos industriales.
Asimismo, el patrón Boundary-Control-Entity, descrito hace décadas por Jacobson, introduce una separación clara y efectiva de responsabilidades, adelantándose a muchos conceptos que hoy parecen revolucionarios pero ya estaban bien establecidos.
Las arquitecturas basadas en capas abordan de manera integral problemas de cohesión, acoplamiento y evolución de sistemas complejos, ofreciendo perspectivas más holísticas y aplicables que SOLID.
Me preocupa especialmente cómo se enseña SOLID en la actualidad. Generalmente, estos principios se presentan como recetas rápidas y acrónimos fáciles de memorizar, sin ofrecer un contexto histórico o una reflexión crítica. Esta pedagogía basada en la inmediatez —popularizada por tutoriales breves y conferencias superficiales— debilita la formación de los profesionales y erosiona la calidad del desarrollo de software.
La repetición mecánica de estos conceptos se ha priorizado sobre la comprensión real y profunda, alejando a los desarrolladores de las fuentes originales bajo el pretexto de que “son viejas o poco prácticas”. Esta actitud limita el pensamiento crítico y empobrece notablemente nuestra profesión.
Hacia una pedagogía más profunda y reflexiva
No propongo abandonar SOLID, sino situarlo en su justa dimensión. Necesitamos recuperar una enseñanza del diseño de software basada en:
- Un estudio profundo y detallado de conceptos fundamentales como cohesión, acoplamiento, modularidad y encapsulamiento.
- Una lectura crítica y enriquecedora de autores clásicos y contemporáneos.
- La comprensión de patrones y arquitecturas como soluciones adaptativas según el contexto, evitando dogmas y recetas universales.
- El fomento de debates, reflexiones constantes y el pensamiento crítico como base para un desarrollo profesional robusto y consciente.
Un llamado a salir de la caverna
Hoy más que nunca, siento la necesidad urgente de alzar la voz frente al conformismo intelectual imperante en nuestra industria. SOLID no es inherentemente perjudicial, pero ha sido malinterpretado y aplicado de manera simplista e irreflexiva.
El verdadero peligro no radica en aplicar estos principios, sino en creer que bastan para asegurar un buen diseño. La arquitectura del software es una disciplina exigente, que requiere rigor intelectual, humildad, estudio profundo y constante. Salir de la caverna del simplismo hacia la claridad del conocimiento profundo es, ahora mismo, nuestra tarea más importante