SOLID es un conjunto popular de principios de diseño que se utilizan en el desarrollo de software orientado a objetos. SOLID es un acrónimo que significa cinco principios clave de diseño: Single responsibility principle (principio de responsabilidad única), Open-closed principle (principio de abierto-cerrado), Liskov substitution principle (principio de sustitución de Liskov), Interface segregation principle (principio de segregación de interfaz) y Dependency inversion principle (principio de inversión de dependencia). Los cinco son comúnmente utilizados por ingenieros de software y brinda algunos beneficios importantes para los desarrolladores.

Los principios SOLID fueron desarrollados por Robert C. Martin en un ensayo publicado en el año 2000, “Principios de diseño y patrones de diseño”, aunque el acrónimo fue acuñado más tarde por Michael Feathers. En su ensayo, Martin reconoció que el software exitoso cambiará y se desarrollará. A medida que cambia, se vuelve cada vez más complejo. Sin buenos principios de diseño, Martin advierte que el software se vuelve rígido, frágil, inmóvil y viscoso. Los principios SOLID se desarrollaron para combatir estos patrones de diseño problemáticos.

El objetivo general de los principios SOLID es reducir las dependencias para que los ingenieros cambien un área del software sin afectar a otras. Además, están destinados a facilitar la comprensión, el mantenimiento y la ampliación de los diseños. En última instancia, el uso de estos principios de diseño facilita que los ingenieros de software eviten problemas y creen software adaptable, eficaz y ágil.

Si bien los principios tienen muchos beneficios, seguir los principios generalmente conduce a escribir un código más largo y complejo. Esto significa que puede extender el proceso de diseño y hacer que el desarrollo sea un poco más difícil. Sin embargo, este tiempo y esfuerzo extra vale la pena porque hace que el software sea mucho más fácil de mantener, probar y ampliar.

5 Principios que todo programador debe conocer

Seguir estos principios no es una panacea y no evitará problemas de diseño. Dicho esto, los principios se han vuelto populares porque cuando se siguen correctamente, conducen a un mejor código en cuanto a legibilidad, mantenibilidad, patrones de diseño y capacidad de prueba. 

1. Single Responsibility Principle, Principio de Responsabilidad Única

Con este principio se exige que “una clase debe tener una, y solo una, razón para cambiar”. Seguir este principio significa que cada clase solo hace una cosa y cada clase o módulo solo tiene la responsabilidad de una parte de la funcionalidad del software. Más simplemente, cada clase debe resolver un solo problema.

El principio de responsabilidad única es un principio relativamente básico que la mayoría de los desarrolladores ya utilizan para crear código. Se puede aplicar a clases, componentes de software y microservicios.

La utilización de este principio hace que el código sea más fácil de probar y mantener, hace que el software sea más fácil de implementar y ayuda a evitar efectos secundarios imprevistos de cambios futuros.

2. Open-Closed Principle, Principio de Abierto-Cerrado

La idea del principio abierto-cerrado es que las clases existentes y bien probadas deberán modificarse cuando sea necesario agregar algo. Sin embargo, cambiar de clase puede generar problemas o errores. En lugar de cambiar la clase, simplemente desea extenderla. Con ese objetivo en mente, Martin resume este principio: “Debería poder extender el comportamiento de una clase sin modificarlo”.

Seguir este principio es esencial para escribir código que sea fácil de mantener y revisar. Su clase cumple con este principio si es:

• Abierto para extensión, lo que significa que el comportamiento de la clase se puede extender; y
• Cerrado por modificación, lo que significa que el código fuente está configurado y no se puede cambiar.

A primera vista, estos dos criterios parecen ser contradictorios. La forma de cumplir con estos principios y asegurarse de que su clase sea fácilmente extensible sin tener que modificar el código es mediante el uso de abstracciones. Usar herencia o interfaces que permitan sustituciones polimórficas es una forma común de cumplir con este principio. Independientemente del método utilizado, es importante seguir este principio para escribir código que se pueda mantener y revisar.

3. Liskov Substitution Principle, Principio de Sustitución de Liskov

De los cinco principios SOLID, el principio de sustitución de Liskov es quizás el más difícil de entender. En términos generales, este principio simplemente requiere que cada clase derivada sea sustituible por su clase principal. El principio lleva el nombre de Barbara Liskov, quien introdujo este concepto de subtipificación conductual en 1987. La propia Liskov explica el principio diciendo:

De una manera más clara, podemos decir que:

Si bien este puede ser un principio difícil de internalizar, en muchos sentidos es simplemente una extensión del principio abierto-cerrado, ya que es una forma de garantizar que las clases derivadas amplíen la clase base sin cambiar el comportamiento.

4. Interface Segregation Principle, Principio de Segregación de Interfaz

La idea general del principio de segregación de interfaces es que es mejor tener muchas interfaces más pequeñas que algunas más grandes. Martin explica este principio al aconsejar:

Para los ingenieros de software, esto significa que no desea simplemente comenzar con una interfaz existente y agregar nuevos métodos. En su lugar, comience creando una nueva interfaz y luego deje que su clase implemente múltiples interfaces según sea necesario. Las interfaces más pequeñas significan que los desarrolladores deberían tener preferencia por la composición sobre la herencia y por el desacoplamiento sobre el acoplamiento. De acuerdo con este principio, los ingenieros deben trabajar para tener muchas interfaces específicas del cliente, evitando la tentación de tener una gran interfaz de propósito general.

5. Dependency Inversion Principle, Principio de Inversión de Dependencia

Este principio ofrece una forma de desacoplar los módulos de software. En pocas palabras, el principio de inversión de dependencia significa que los desarrolladores deben “depender de abstracciones, no de concreciones”. Con este principio “los módulos de alto nivel no deben depender de los módulos de bajo nivel. Ambos deberían depender de abstracciones”. Además, “las abstracciones no deberían depender de los detalles. Los detalles deberían depender de las abstracciones”.

Una forma popular de cumplir con este principio es mediante el uso de un patrón de inversión de dependencia, aunque este método no es la única forma de hacerlo. Independientemente del método que elija utilizar, encontrar una manera de utilizar este principio hará que su código sea más flexible, ágil y reutilizable.

Conclusión

La implementación de los principios de diseño SOLID durante el desarrollo conducirá a sistemas que son más fáciles de mantener, escalables, comprobables y reutilizables. En el entorno actual, estos principios son utilizados globalmente por los ingenieros. Como resultado, para crear un buen código y usar principios de diseño que sean competitivos y cumplan con los estándares de la industria, es esencial utilizar estos principios.

Ejemplos

En este artículo se pueden encontrar algunos ejemplos para cada uno de los principios SOLID, están en JAVA, pero pueden ser aplicados a cualquier lenguaje de programación que permita el desarrollo de aplicaciones con OOP: https://www.baeldung.com/solid-principles