Principios SOLID: 5 claves para tu desarrollo de software

Cuando se trata de programación, diseño, ingeniería, arquitectura y desarrollo de software, los principios SOLID juegan un papel primordial porque son absolutamente vitales para los profesionales del desarrollo web. 

Los cinco Principios SOLID son la base del diseño de clases orientado a objetos y abarcan algunas de las mejores prácticas para la arquitectura de software. En la práctica, pueden traducirse en resultados extraordinarios en todas las fases del desarrollo.

Si buscas iniciar tu camino como desarrollador, los Principios SOLID son indispensables. Y en este artículo, te contaremos qué son, en qué consisten, por qué son tan importantes y cómo pueden ayudarte a perfeccionar tus técnicas de desarrollo y arquitectura de software.

¿Qué es SOLID?¿Cuáles son los Principios SOLID?

SOLID es un acrónimo que agrupa 5 principios clave para el desarrollo eficiente, replicable, mantenible y escalable de software. Estos Son:

• S - Single Responsibility Principle (SRP) o Principio de Responsabilidad Única.

• O - Open/Closed Principle (OCP) o Principio de Código Abierto - Cerrado.

• L - Liskov Substitution Principle (LSP) o Principio de Sustitución de Liskov.

• I - Interface Segregation Principle (ISP) o Principio de Segregación de Interfaz.

• D - Dependency Inversion Principle (DIP) o Principio de Inversión de Dependencia.

Para entender mejor los Principios Solid, tenemos que entender cómo y de dónde surgen.

SOLID es un acrónimo propuesto por el desarrollador de software Michael Feathers en su libro «Working Effectively with Legacy Code». Sin embargo, Feathers tomó los principios ya propuestos  por el ingeniero de software Robert C. Martin, también conocido como «Uncle Bob» en su ensayo «Principios de diseño y patrones de diseño».

Uncle Bob señaló en su ensayo que el software exitoso estaba destinado a volverse más y más complejo. En otras palabras, el software exitoso sigue creciendo, haciéndose más amplio, profundo y, por tanto, difícil de trabajar.

Desde entonces, los Principios SOLID se han convertido en una de las prácticas preferidas en el mundo del desarrollo.

Los 5 Principios SOLID

Veamos en qué consiste cada uno de los Principios SOLID y cómo aplicarlos:

1. Single Responsibility Principle (SRP) o Principio de Responsabilidad Única

“Every class should have a single responsibility: It should have a single purpose in the system, and there should be only one reason to change it.”

«Toda clase debería tener una sola responsabilidad: esta debería tener un solo propósito en el sistema, y solo debería haber una razón para cambiarla».

¿Y esto qué significa?

Según este principio, cada clase debería tener una única responsabilidad. O en otras palabras, un solo trabajo. Y este principio puede aplicarse a clases, componentes y microservicios.

Al trabajar con código heredado, los desarrolladores pueden modificar las clases por múltiples razones, lo que podría llevar a errores y módulos incompatibles. 

Dicho de otro modo, las clases saturadas saturan el sistema y pueden llevarlo a colapsar. En cambio, al concederles un solo propósito, son mucho más fáciles de segmentar y de corregir en caso de errores, lo que te ayuda a organizar las clases y hacerlas más escalables.

Además, el SRP previene problemas de fusión y compatibilidad en diferentes equipos y sistemas y facilita la colaboración entre equipos de desarrollo. 

2. Open/Closed Principle (OCP) o Principio de Código Abierto/Cerrado

“…code should be open for extension but closed to modification. When we have a good design, we just don’t have to change code much to add new features.”

«El código debería estar abierto a la extensión pero cerrado a la modificación. Si tenemos un buen diseño [de código] no tenemos que cambiar tanto código para agregar nuevas funciones».

En otras palabras, en lugar de cambiar el código de una clase existente, se debe agregar una nueva funcionalidad para evitar posibles errores, tanto de compatibilidad como de código heredado.

Este principio suele ejecutarse a través de interfaces y clases abstractas. Estas son capaces de darle más flexibilidad al código y hacerlo más extensible. 

Al no modificar el código, puedes preservar el código probado, evitar errores y facilitar tanto el mantenimiento como la evolución del software. Y en el caso de que una de las extensiones no funcione, puedes eliminarla sin dañar el código original.

Nota: este principio puede ser controversial. Si agregas demasiadas extensiones y no usas el diseño adecuado, el código puede volverse excesivamente complicado y difícil de mantener, lo que puede generar más errores. 

3. Liskov Substitution Principle (LSP) o Principio de Sustitución de Liskov

“Objects of subclasses should be substitutable for objects of their superclasses throughout our code”.

«Los objetos de las subclases deberían ser reemplazables por objetos de sus clases superiores a lo largo del código».

Dicho de otro modo, los objetos deben poder reemplazarse por sus respectivas clases inferiores sin afectar la integridad del programa ni el funcionamiento del sistema.

Este principio garantiza la operatividad del sistema. Además, permite que puedas reemplazar instancias de claves derivadas SIN tocar las instancias de la clase base, lo que permite extender el software sin errores en su código base.

4. Interface Segregation Principle (ISP) o Principio de Segregación de Interfaz

“A client-specific interface for a particular set of clients.”

«Una interfaz específica de cliente para cada tipo particular de clientes».

En otras palabras, es mejor contar con muchas interfaces para clientes específicos que una sola interfaz general para muchos tipos de clientes.

Una interfaz como la última suele contener un sinnúmero de funciones y métodos para muchos tipos de cliente. 

En la práctica, la gran mayoría de estos métodos no se usan y pueden entorpecer el funcionamiento del sistema.  Siempre es mejor una interfaz más pequeña y específica.

Bajo este principio, los clientes solo deben depender de las interfaces que utilicen o vayan a utilizar. Así, puedes desarrollar una interfaz mejor personalizada, más fácil de acoplar y mucho más flexible. 

Por tanto, Uncle Bob recomienda evitar las interfaces genéricas. Una interfaz específica para cada cliente requiere de más trabajo. Pero, a largo plazo, será muchísimo más fácil de manejar, corregir y extender. 

5. Dependency Inversion Principle (DIP) o Principio de Inversión de Dependencia

“It is better to depend on interfaces or abstract classes than it is to depend on concrete classes.”

«Es mejor depender de interfaces o clases abstractas que depender de clases concretas»

 E igualmente:

 «Las abstracciones no deberían depender de los detalles. Los detalles son los que deberían depender de las abstracciones.

En palabras del propio Martin, según este principio, las clases concretas son más volátiles. Y mientras menos dependes de cosas volátiles menores serán tus probabilidades de disparar recompilaciones masivas. 

Esto se traduce a que los módulos de alto nivel no deben depender de módulos de bajo nivel. Asimismo, y siguiendo el principio anterior, es mejor depender de interfaces específicas que de clases concretas.

Bonus: el código limpio y su relación con los Principios SOLID

Si eres nuevo en el mundo del desarrollo de software, vas a ver este término una y otra vez. Éste se refiere a un estilo de escritura de código legible, comprensible y fácil de mantener, así como las prácticas para redactar mejor.

El código limpio es la razón de ser detrás de los Principios SOLID.

En la práctica, el código limpio no solo es más funcional, sino que puede brindar resultados alucinantes a los equipos de desarrollo, especialmente cuando hablamos del legacy code, o código heredado. 

El código limpio también se relaciona al principio KISS (Keep It Simple, Stupid, o «Mantenlo Simple, Estúpido»). Misma base de los Principios SOLID Y por supuesto, base de muchas metodologías ágiles para el desarrollo de software.

Por un lado, los Principios SOLID proporcionan pautas para el diseño de código modular y de calidad. Por otro lado, el código limpio es el resultado de aplicar estas pautas y buenas prácticas para producir un código más legible, funcional y fácil de mantener.

6 Beneficios de los Principios SOLID

Muy bien, veamos por qué los Principios SOLID cuentan con tanta acogida en el mundo del desarrollo de software y por qué deberían ser parte de tu repertorio. 

Algunas de estas son, pero no se limita a:

• Lectura de código: los Principios SOLID están focalizados hacia el código limpio y la arquitectura clara, eficiente y funcional. En la práctica, este código es mucho más fácil de leer y mucho más eficiente en todas las facetas del desarrollo.

• Facilidad de mantenimiento: estos también facilitan la implementación de código limpio. A largo plazo, gracias a su estructura clara y segmentada, el código puede mantenerse con más facilidad sin perjudicar al funcionamiento del sistema.

• Capacidad de extensión: o «extensibilidad». El código puede extenderse sin afectar ni perjudicar el código base. El resultado es una estructura modular, flexible, dinámica, mejor segmentada y mucho más organizada. 

• Testeabilidad: gracias a estos principios, el código será mucho más fácil de probar y los errores serán más fáciles de detectar, incluso cuando este pase por diferentes desarrolladores. Además, los principios son perfectos para ejecutar pruebas unitarias y pruebas de integración de forma aislada, sin afectar el código base.

• Reutilización: códigos, componentes y modelos replicables. En otras palabras, puedes aprovechar el código ya creado en distintos contextos y proyectos ya que solo tendrás que modificar clases específicas y no necesitarás reescribir grandes cantidades de código.

• Colaboración: los Principios SOLID buscan promover las prácticas y mejorar los estándares del código heredado. Las pautas y protocolos no solo son claros, sino que son funcionales y fáciles de estructurar y de seguir. Por tanto, el código resulta mucho más eficiente para los trabajos en conjunto.

Desventajas de los Principios SOLID

Porque para obtener la perspectiva completa de los principios SOLID, también hay que saber cuáles son sus contras. Las más importantes son las siguientes:

• Complejidad: las interfaces específicas para cada cliente, por ejemplo, son más desafiantes y requieren de más tiempo, esfuerzo e inversión.

• Diseño excesivo o sobrediseño: las clases añadidas, por ejemplo, son un arma de doble filo. Añadir y seguir añadiendo clases de forma excesiva, sin el diseño ni la planeación correctas, hace al código más complejo, difícil de manejar y más propenso a errores.

• Curva de aprendizaje: por el énfasis en la estructura y la separación de responsabilidades. En la práctica, implementar los Principios SOLID puede ser desafiante para los desarrolladores novatos.

• Rigidez: seguir los principios al pie de la letra sin importar los diferentes escenarios puede obstaculizar otras fases del proceso de desarrollo. 

Y aquí haremos una acotación.

Los Principios SOLID son exactamente eso: principios. Fueron creados para facilitar el trabajo de los desarrolladores, facilitar la implementación del código limpio y promover buenas prácticas de desarrollo. 

Consideraciones al aplicar los principios

Estos principios son herramientas excepcionales y pueden darte resultados magníficos, pero no son y no deben verse como reglas absolutas. 

En otras palabras, son medios para una meta, pero no son la meta del desarrollo de software..

Los Principios SOLID pueden aplicarse a todas las fases de la programación orientada a objetos (OOP por sus siglas en inglés) así como a la programación funcional (FP) y a la programación multiparadigma. 

Aun así, siempre deben aplicarse con la planeación y las metodologías correctas. Y sobre todo, sin exceso de rigidez. La rigidez y la rigurosidad excesiva pueden convertir a estos principios en la meta final y entorpecer el proceso de desarrollo.

A su vez, aunque estos principios son conocidos y aplicados en todo el mundo, no todos los aplican de la misma forma. 

Por ello, al iniciar o al unirte a un proyecto, tienes que verificar si se aplican los principios y cómo se aplican para que tú y tu equipo se mantengan en la misma página. 

¿Listo para poner en práctica los Principios SOLID?

Bien aplicados, los Principios SOLID te ayudarán a integrar las mejores prácticas en tu desarrollo de software. Te permitirán mantener estructuras de código impecables, fáciles de replicar, corregir y optimizar en todo tipo de escenarios. 

Además, serán de gran ayuda a la hora de trabajar en proyectos conjuntos y te ayudarán a evitar problemas de integración, compatibilidad y otros problemas de código heredado.

Y si quieres ir más allá, lo mejor es seguir evolucionando como desarrollador de software. Si quieres especializarte como desarrollador, puedes darle un vistazo a nuestras diferentes formaciones y herramientas. 

Allí, encontrarás todo lo que necesitas para implementar los Principios SOLID en diferentes lenguajes y escenarios. Además, descubrirás con qué herramientas, lenguajes, recursos y metodologías los puedes complementar.

Y ahora, tu turno.

Cuéntanos en los comentarios si ya habías escuchado de estos principios y cómo podrían ayudarte en tus proyectos, y si tienes alguna pregunta que quizá se nos haya escapado de nuestro artículo.

Y si te ha gustado, también puedes compartir este artículo en tus redes sociales.