En noviembre de 2002, Bob Martin publicaba el libro Agile Software Development, Principles, Patterns and Practices, y entre otras cosas, en el enunciaba los famosos Principios SOLID.

Estos principios conforman un acrónimo que refleja claramente su intencionalidad, crear software sólido y robusto:

• Single Responsability Principle (SRP)

• Open/Closed Principle (OCP)

• Liskov Substitution Principle (LSP)

• Interface Segregation Principle (ISP)

• Dependency Inversion Principle (DIP)

En este post, hablaremos del primero de ellos el principio de única responsabilidad (SRP). Vamos a ello!

Definición

El Principio de Única Responsabilidad (SRP) es el más conciso y sencillo de entender:

Una clase debería de tener una única responsabilidad.

¿Qué quiere decir esto? Resulta obvio, una clase debe de producir un objeto especializado, concreto, con una única finalidad. Siendo más específico: solo debe de tener una razón de cambio.

La razón de cambio es el motivo por el cual deberíamos de cambiar el código de nuestra clase. Imaginemos por un momento una clase encargada de escribir un log de nuestra aplicación, de entrada hay dos motivos de cambio:

• Destino de la salida de log: archivos de texto de diferentes formatos, base de datos, servicios en línea…

• Contenido de la salida: El string de salida con las información deseada (fecha en el formato adecuado, mensaje…)

El SRP nos dice que debemos de separar en dos clases diferentes estas dos responsabilidades: formatear la salida por una parte y escribir la salida en su destino.

Esta separación de conceptos nos permite a futuro cambiar el comportamiento de nuestra aplicación y hacer nuestro log más versátil. Por ejemplo: podemos tener más de una implementación que dé formato al string de salida y más de una que vuelque la salida a distintos destinos, y podemos inicializar nuestro log con cualquier combinación de estas implementaciones.

Code Smells

Martin Fowler definió como olores en el código (code smells) a una serie de síntomas superficiales en nuestro código que nos alertan de que, probablemente, nuestro código tenga problemas de diseño más profundos.

“A code smell is a surface indication that usually corresponds to a deeper problem in the system”. — Martin Fowler

El termino fue acuñado por Kent Beck en el libro *Refactoring: Improving the Design of Existing Code *publicado en 1999 junto con Martin Fowler.

¿A qué huele una clase que no cumple con el SRP?

En otras palabras: cómo podemos detectar que una clase de nuestro código no tiene una única responsabilidad? Aquí una lista que debería hacer saltar nuestras alarmas:

• Exceso de métodos públicos. Muchos métodos públicos indican muchas funcionalidades, difícilmente pertenecerán todas a una única responsabilidad.

• Excesivo número de imports. Demasiadas referencias a otras clases indican muchas dependencias externas y esto puede significar que nuestra clase hace muchas cosas.

• Cada nueva funcionalidad afecta a esta clase. Si cada cambio en nuestra aplicación afecta a esta clase, esta tiene demasiadas responsabilidades.

• Excesivo número de líneas de código. Si nuestra clase solo tiene una única responsabilidad, su número de líneas no debería ser muy elevado.

• En la misma clase están involucradas varias capas de la arquitectura. Si nuestra clase hace cosas como acceder a base de datos o renderiza vistas, además de ejecutar la lógica de negocio. Esta clase hace demasiadas cosas.

¿Cómo solucionamos el SRP?

La solución es a la vez sencilla y complicada. Sencilla porque realmente ya tenemos todo el código necesario para que funcione, solo es necesario reorganizar nuestro código en distintas clases. Complicada porque a veces no es sencillo identificar las diferentes responsabilidades, pero como todo en esta vida, la práctica hace al maestro ;)

Hasta la próxima!