[vc_row][vc_column][vc_column_text]SOLID es uno de los más populares conjuntos de principios de diseño en el desarrollo de software orientado a objetos. Es un acrónimo de los principios en inglés. Los principios son los siguientes:
- Principio de la responsabilidad individual
- Principio Abierto/Cerrado
- Principio de sustitución de Liskov
- Principio de la segregación de la interface
- Inversión de Dependencia
Todos ellos son ampliamente utilizados y vale la pena conocerlos. Pero en este artículo relacionado a los principios SOLID, nos centraremos en: Principio de Responsabilidad Individual.
Robert C. Martín lo describe como:
Una clase debe tener una, y solo una, razón para cambiar.
Incluso si nunca ha oído hablar de Robert C. Martín o sus libros, es probable que hay escuchado y utilizado este principio. Es uno de los principios básicos que la mayoría de desarrolladores aplican para crear un software robusto y fácil de mantener. No solo puede aplicarlo a clases, sino también a componentes de software y microservicios.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
Beneficios del Principio de Responsabilidad Individual
A continuación presentamos las preguntas más importantes antes de sumergirnos más profundamente en este principio de diseño: ¿Por qué debería utilizarlo y qué sucede si lo ignora?
El argumento para el principio de responsabilidad única es relativamente simple: hace que su software sea más fácil de implementar y evita los defectos secundarios inesperados de los cambios futuros.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
Frecuencia y Efecto de los cambios
Todos sabemos que los requisitos cambian con el tiempo. Cada uno de ellos también cambia la responsabilidad de al menos una clase. Cuantas más responsabilidades tiene una clase, más a menudo necesita cambiarla. Si su clase implementa múltiples responsabilidades, ya no son independientes entre sí.
Necesita cambiar su clase tan pronto como una de las responsabilidades cambie. Obviamente, es más frecuente de lo que necesitaría cambiar si solo tuviera una responsabilidad.
Eso puede no parecer un gran problema, pero también afecta a todas las clases o componentes que dependen de la clase modificada. Dependiendo de su cambio, es posible que necesite actualizar las dependencias o recompilar las clases dependientes, a pesar de que el cambio no las afecte directamente. Solo usan una de las otras responsabilidades implementadas por su clase, pero necesita actualizarlas de todos modos.
Al final, necesita cambiar su clase con más frecuencia, y cada cambio es más complicado, tiene más efectos secundarios y requiere mucho más trabajo de lo que debería. Entonces, es mejor evitar estos problemas asegurándose de que cada clase tenga solo una responsabilidad.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
Más fácil de entender
El principio de responsabilidad única proporciona otro beneficio sustancial. Las clases, los componentes de software y los microservicios que tienen una sola responsabilidad son mucho más fáciles de explicar, comprender e implementar que los que proporcionan una solución para todos. Esto reduce la cantidad de errores, mejora su velocidad de desarrollo y hace que su vida como desarrollador de software se mucho más fácil.
Una pregunta simple para validar su diseño
Desafortunadamente, seguir el principio de responsabilidad única suena mucho más fácil de lo que suele ser.
Si construye su software durante un período más largo y si necesita adaptarlo a los requisitos cambiantes, podría parecer que el enfoque más fácil y rápido es agregar un método o funcionalidad a su código existente en lugar de escribir una nueva clase o componente. Pero eso a menudo resulta en clases con más responsabilidad y hace que sea cada vez más difícil mantener el software.
Puede evitar estos problemas haciendo una simple pregunta antes de realizar cualquier cambio: ¿Cuál es la responsabilidad de su clase/componente/microservicio?
Si tu respuesta incluye la palabra «y», lo más probable es que rompas el principio de responsabilidad individual. Entonces es mejor dar un paso atrás y reconsiderar su enfoque actual. Probablemente haya una mejor manera de implementarlo.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
Ejemplos del mundo real del principio de responsabilidad única
Puede encontrar muchos ejemplos de todos los principios de diseño SOLID en el software de código abierto y en la mayoría de las aplicaciones bien diseñadas, como la capa de persistencia de Java y los frameworks y especificaciones populares, que probablemente ha utilizado.
Uno de ellos es la implementación de Java Persistence API (JPA). Tiene una, y solo una responsabilidad: la definición de una forma estandarizada para gestionar base de datos persistentes en una base de datos relacional mediante el uso del mapeo relacional de objetos.
Esa es una gran responsabilidad. La especificación define muchas interfaces diferentes para él, especifica un conjunto de estados del ciclo de vida de la entidad y las transiciones entre ellos, e incluso proporciona un lenguaje de consulta, llamado JPQL.
Pero esa es la única responsabilidad de la especificación JPA. Otras funcionalidades que podría necesitar para implementar su aplicación, como validación, API REST o registro en un archivo log, no son responsabilidad de JPA. Debe incluir otras especificaciones u otros frameworks que brindan estas características.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
Resumen
El principio de responsabilidad única es uno de los principios de diseño más utilizados en la programación orientada a objetos. Puede aplicarlos a clases, componentes de software y microservicios.
Para seguir este principio, su clase no puede tener más de una responsabilidad, por ejemplo, la gestión de entidades o la conversión de tipos de datos. Esto evita cualquier acoplamiento técnico innecesario entre las responsabilidades y reduce la probabilidad de que necesite cambiar su clase. También reduce la complejidad de cada cambio porque reduce el número de clases dependientes que se ven afectadas por él.
Este artículo se encuentra basado en SOLID Design Principles Explained – The Single Responsibility Principle[/vc_column_text][/vc_column][/vc_row]
