SOLID es un acrónimo que agrupa cinco principios de diseño orientado a objetos: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation y Dependency Inversion. Robert C. Martin (conocido como "Uncle Bob") articuló estos cinco principios en un paper del año 2000; fue Michael Feathers quien, unos años después, se dio cuenta de que sus iniciales formaban la palabra SOLID y así quedó bautizado el conjunto.

Las cinco letras, una por una

Single Responsibility dice que una clase debería tener una sola razón para cambiar: si mezcla lógica de negocio con lógica de guardar en base de datos, cualquier cambio en cualquiera de las dos partes obliga a tocar la misma clase. Open/Closed dice que el código debería poder extenderse con comportamiento nuevo sin modificar el código ya existente y probado, típicamente añadiendo una implementación nueva en vez de editando un condicional que ya funciona. Liskov Substitution dice que si una clase hija sustituye a su clase padre en cualquier parte del programa, todo debería seguir funcionando igual, sin sorpresas. Interface Segregation dice que es mejor tener varias interfaces pequeñas y específicas que una sola interfaz enorme que obliga a implementar métodos que no se necesitan. Dependency Inversion dice que el código de alto nivel no debería depender de detalles concretos de bajo nivel, sino de abstracciones —por ejemplo, depender de una interfaz de "repositorio" en vez de depender directamente de una base de datos concreta.

Por qué importan en la práctica

El hilo común entre los cinco es reducir el acoplamiento: cuanto más depende una parte del código de los detalles internos de otra, más caro resulta cambiar cualquiera de las dos sin romper algo. Ignorar el principio de responsabilidad única en particular suele ser una fuente silenciosa de deuda técnica, porque cada nueva función que se añade a una clase que ya hace demasiado hace que la siguiente modificación sea un poco más arriesgada que la anterior. Aplicar SOLID no es lo mismo que escribir clean code, pero ambos objetivos apuntan en la misma dirección: que el código sea fácil de entender y de cambiar con confianza.

Un matiz importante: no son dogma

Aplicar los cinco principios a rajatabla en cualquier situación puede producir el problema contrario al que intentan resolver: demasiadas interfaces diminutas, demasiadas capas de abstracción para un problema que en realidad era simple. SOLID tiene más sentido cuando el código va a cambiar con frecuencia o cuando distintas partes del equipo trabajan sobre las mismas piezas; para un script pequeño y de un solo uso, aplicar los cinco principios puede ser más esfuerzo del que el problema justifica. Estos principios también son un lenguaje común útil durante un code review, para explicar con precisión por qué un cambio concreto está complicando el diseño más de lo necesario, en vez de quedarse en un "esto no me convence" difícil de argumentar.

Fuentes:

• DigitalOcean — SOLID: The First 5 Principles of Object-Oriented Design
• Wikipedia — Robert C. Martin