Al momento de iniciarte en el camino de la Programación Orientada a Objetos, lo más seguro es que te hayas encontrado con los principios SOLID. Aplicar correctamente estos 5 principios te permitirá escribir código limpio, bien estructurado y fácil de mantener.
En este primer artículo abarcaremos la "S" de Single Responsibility Principle ¿qué esperas? ¡Acompáñanos!
Historia
El término fue introducido por Robert C. Martin y se popularizó gracias a su libro Agile Software Development, Principles, Patterns, and Practices. Martin describió que su fuente de inspiración fue el principio de cohesión, descrito por Tom DeMarco en su libro Structured Analysis and System Specification, y Meilir Page-Jones en The Practical Guide to Structured Systems Design. En 2014 Martin escribió un blog nombrado The Single Responiability Principle, su objetivo fue dejar claro a que exactamente se refería con "razón para cambiar" y es esto lo que estudiaremos a continuación.
SRP: Principio de Responsabilidad Única
Una clase debería tener una única responsabilidad.
El principio de responsabilidad única establece que cada clase debería ser responsable únicamente de una parte de la funcionalidad que proveerá nuestro software. Esto suena bien, pero... ¿a qué se refiere con "ser responsable"?
¿Qué es una responsabilidad?
En el contexto de este principio una responsabilidad puede ser definida como “una razón para cambiar”. Si sustituimos “responsabilidad” por “razón para cambiar” nos queda:
Una clase debería tener solo una razón para cambiar.
Ahora... ¿cómo identificamos que nuestras clases tienen solo una razón para cambiar?
Identificando una razón para cambiar
Básicamente si podemos pensar acerca de más de un motivo para cambiar una clase (cuando tenemos que desarrollar un nuevo requerimiento, por ejemplo) entonces tiene más de una responsabilidad. Veamos un ejemplo. A continuación verás la clase Rectangulo.
¿Logras identificar si tiene una o más responsabilidades?
Esta clase tiene dos métodos, dibujar se encarga de dibujar un rectángulo en pantalla. Por otro lado, area se encarga de computar el área del rectángulo. Esto a primera vista parece tener sentido. Ambos métodos guardan relación con el rectángulo, uno lo dibuja, otro retorna su área.
Separando responsabilidades acopladas
Si prestamos atención detenidamente podremos notar que esta clase tiene dos responsabilidades. Esto es a veces complicado de ver debido a que estamos acostumbrados a pensar acerca de las responsabilidades en grupo, como un conjunto. La primera responsabilidad es dibujar el rectángulo en pantalla. La segunda, calcular su área. Observemos la siguiente situación:
A simple vista podemos notar que la AplicacionGeometriaComputacional hace uso de el método area. AplicacionGrafica hace uso tanto del método dibujar como de la GUI (Interfaz gráfica de Usuario) por otras razones. Finalmente Rectangulo necesita GUI para poder dibujar el rectángulo en pantalla.
¿Qué posibles consecuencias trae que nuestras clases tengan más de una responsabilidad?
Cada responsabilidad es un eje de cambio. Cuando los requerimientos cambian, ese cambio se verá reflejado en las responsabilidades a lo largo de las clases. Si una clase tiene más de una responsabilidad, habrá entonces más de una razón para que cambie. Lo que implica que el cambio a una de ellas puede afectar a la otra, incluso nos puede imposibilitar satisfacer ambas.
Este tipo de acoplamiento puede generar diseños frágiles que romperán nuestras aplicaciones de maneras imprevistas al introducir cambios. Y es esto lo que este principio busca fundamentalmente, limitar el impacto al introducir cambios a lo largo de nuestras aplicaciones. Retomemos nuestro ejemplo anterior para ilustrar esto.
Un posible inconveniente que nos encontremos al momento de aplicar un cambio en AplicacionGrafica es, que si este cambio hace que Rectangulo cambie por alguna razón, nos veremos obligados a compilar, probar y desplegar nuevamente AplicacionGeometriaComputacional. Si olvidamos hacer esto, nuestra aplicación puede romperse de manera imprevista. Son estas situaciones las que este principio busca evitarnos.
Un mejor diseño es separar estas dos responsabilidades en dos clases completamente distintas. Este diseño separa la responsabilidad de computar valores a la clase RectanguloGeometrico, de este modo cambios en el modo en el que los rectángulos son renderizados no pueden afectar a AplicacionGeometriaComputacional.
Conclusión
El principio de responsabilidad única es el más simple de los principios, y uno de los más difíciles de aplicar correctamente. Acoplar responsabilidades es algo que hacemos naturalmente. Encontrar y separar cada una de ellas es básicamente de lo que se trata el diseño de software. Aplicarlo correctamente nos facilitará el mantenimiento de nuestras aplicaciones, teniendo en cuenta que no sólo aplica a clases, sino a módulos y funciones.
Es importante tener presente que un eje de cambio lo es únicamente si los cambios realmente ocurren. No es prudente utilizar el principio de responsabilidad única o cualquier otro principio si no hay ningún síntoma.
Te dejo una reflexión para finalizar. Esta refleja la situación en la que nos vemos al momento de introducir cambios en nuestra aplicación.
Imagina que llevas tu auto al mecánico para que arregle una ventana eléctrica que está rota. El te llama al día siguiente para avisarte de ya está arreglado. Cuando recoges tu auto, te das cuenta de que la ventana funciona de maravilla; pero el auto no enciende. Lo más seguro es que no vuelvas a ese mecánico porque claramente es un idiota.
El propósito de este principio siempre fueron las personas.
Referencias
James Ellis-Jones. (21 de octubre de 2017). Think you understand the Single Responsibility Principle?. Hackernoon. Recuperado de https://hackernoon.com/you-dont-understand-the-single-responsibility-principle-abfdd005b137
Robert C. Martin. (8 de mayo de 2014). The Single Responsibility Principle. Clean Coder Blog.[Blog]. Recuperado de https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html
Robert C. Martin, (25 de octubre de 2002), Agile Software Development, Principles, Patterns and Practices, Upper Saddle River, New Jersey, Pearson Education, Inc.