"El principio de responsabilidad única".

Consejos de programación para #programadores.

-----------------------------------------------------------------------

LIBRO: 97 COSAS QUE TODO PROGRAMADOR NECESITA SABER.

POR: KEVLIN HENNEY.

-----------------------------------------------------------------------

75° "EL PRINCIPIO DE RESPONSABILIDAD ÚNICA":

Uno de los principios más fundamentales del buen diseño es:

Reunir aquellas cosas que cambian por la misma razón y separar aquellas cosas que cambian por diferentes motivos.

Este principio se conoce a menudo como principio de responsabilidad única o SRP. En resumen, dice que un subsistema, módulo, clase o incluso una función no debería tener más de una razón para cambiar. El ejemplo clásico, es una clase que tiene métodos que tratan con reglas de negocio, informes y bases de datos:

public class Employee {
public Money calculatePay() ...
public String reportHours() ...
public void save() ...
}        

Algunos programadores podrían pensar que juntar estas tres funciones en la misma clase es perfectamente apropiado. Después de todo, se supone que las clases deben ser colecciones de funciones que operan sobre variables comunes, sin embargo, el problema es que las tres funciones cambian por razones completamente diferentes.

La función calculatePay cambiará cada vez que las reglas comerciales hagan cálculos para hacer pagos. La función reportHours cambiará cada vez que alguien quiera un formato diferente para el informe. La función de save cambiará cada vez que los DBA cambien el esquema de la base de datos. Estas tres razones para cambiar, se combinan para hacer un empleado muy volátil. Cambiará por cualquiera de esas razones. Más importante, cualquier clase que dependa del empleado se verá afectada por ésos cambios. Un buen diseño del sistema significa que separamos el sistema en componentes que se pueden implementar de forma independiente. El despliegue independiente significa que si cambiamos un componente, no tenemos que volver a implementar ninguno de los demás. Sin embargo, si muchas otras clases en otros componentes utilizan mucho al empleado, entonces cada ves más es probable que el cambio a Empleado provoque que los otros componentes se vuelvan a implementar, negando así un beneficio importante del diseño de componentes (o SOA, si prefiere el mismo nombre más moderno). La siguiente partición simple resuelve los problemas:

public class Employee {
public Money calculatePay() ...
}
public class EmployeeReporter {
public String reportHours(Employee e) ...
}
public class EmployeeRepository {
public void save(Employee e) ...
}        

Cada clase se puede colocar en un componente propio. O mejor dicho, todos los informes y las clases pueden entrar en el componente de informes. Todas las clases relacionadas con bases de datos puede ir al componente del repositorio. Y todas las reglas comerciales pueden entrar en el componente de reglas de negocio.

El lector astuto verá que todavía existen dependencias en la solución anterior. Las otras clases todavía dependen de ese empleado. Entonces, si se modifica el empleado, es probable que las otras clases tengan que ser recompiladas y reimplementadas. De este modo, el empleado no se puede modificar y luego implementar de forma independiente. Sin embargo, las otras clases se pueden modificar e implementar de forma independiente. Ninguna modificación de uno de ellos puede obligar a cualquiera de los demás a volver a compilarse o implementarse. Incluso el empleado podría desplegarse de forma independiente mediante un uso cuidadoso del principio de inversión de dependencia (DIP), pero ese es un tema para otro libro.*

Una aplicación cuidadosa del SRP, separando las cosas que cambian por diferentes razones, es una de las claves para crear diseños que tengan un efecto independiente y estructura de componentes desplegables.

-Robert C. Martin (Uncle Bob)-