Algo con un propósito, una responsabilidad, siempre va a resultar mucho más fácil de cambiar. Esto es simplemente porque se puede ver mucho más claramente lo que hace y lo que no. Además, como tiene una única responsabilidad, no hay chance de que el cambio en el código pueda afectar a otro código, comportamiento quizás, pero código, no. Y mejora en gran medida la reutilización de código.
Finalmente, el código se hace mucho más fácil de probar ya que se puede realizar el test de una responsabilidad en forma aislada de las demás.
Un ejemplo claro de esto, son las navajas suizas. Tienen un cuchillo, un destapador, un abrelatas, etc. Y cuando uno de ellos se rompe, hay que cambiar la navaja completa.
Yendo al código, que es nuestro campo, podemos ver a continuación un pequeño ejemplo:
Veamos las diferentes responsabilidades que posee la clase ProcesadorDeOrdenes, ellas son:
- El procesamiento de las ordenes.
- La grabación en la base de datos.
- El envío de un mensaje de confirmación.
Rápidamente podemos ver que hay tres responsabilidades bien separadas. Por este motivo, hay tres razones por las cuales ésta clase podría cambiar.
Como se puede observar, hemos sido capaces de separar las diferentes responsabilidades en tres clases separadas (ProcesadorDeOrdenes, Repositorio y Mensajeria). Una mirada a cada una de ellas, nos permite identificar claramente lo que debe estar haciendo. Esto también nos habilita la reutilización de las diferentes responsabilidades.
Nota: SRP es uno de los principios más difíciles de hacer cumplir, porque siempre hay espacio para la refactorización de una clase en varias para que cada cual tenga una sola responsabilidad. Es una preferencia personal, porque la explosión de clases hace que algunas personas se conviertan en fanáticos del código.
0 comentarios:
Publicar un comentario
Muchas gracias por leer el post y comentarlo.