Universidad Laica Eloy Alfaro de Manab

Facultad de Ciencias Informticas

Edgar Jonathan Villegas Zambrano
Sptimo Nivel "B"
Abril, 2014
Manta - Manab -Ecuador
El Principio de responsabilidad nica (Single Responsability Principle - SRP)
1. Introduccin
El Principio de responsabilidad nica (Single Responsability
Principle - SRP) fue acuado por Robert C. Martin en un artculo
del mismo ttulo y popularizado a travs de su conocido libro
[patrones Gof]. SRP tiene que ver con el nivel de acoplamiento
entre mdulos dentro de la ingeniera del software.
Este principio nos viene a decir que una clase slo debera
tener una nica razn para cambiar.
"Una clase debe tener una nica razn para cambiar."
En trminos prcticos, este principio establece que:
"Una clase debe tener una y solo una nica causa por la cual
puede ser modificada."
"Cada clase debe ser responsable de realizar una actividad del
sistema
Lo que trata de decirnos este principio es que debemos huir de
aquellas clases monolticas que aglutinen varias
responsabilidades. Pero, qu es una responsabilidad? Desde el
punto de vista de SRP se podra decir que una responsabilidad en
una clase es una razn para cambiar esa clase. Es decir, si
encontramos que hay ms de una razn por la que una clase pueda
cambiar entonces es que esa clase tiene ms de una
responsabilidad.
1. Contenido
"Cada objeto en el sistema deben tener una simple
responsabilidad, y todos los servicios de los objetos deben
cumplir con esa simple responsabilidad"
Una clase debera tener solo una razn para cambiar, este
principio tiene que ver con responsabilidades, cada objeto en un
diseo tiene que enfocarse en solo una responsabilidad y si esa
responsabilidad cambia, sabremos donde exactamente tenemos que
hacer el cambio en nuestro cdigo.
Este principio ser implementado correctamente cuando cada uno
de nuestras clases tengan solo una razn para cambiar, en
aplicaciones bien diseadas una clase tiene solo una
responsabilidad, hace esta responsabilidad correctamente y no
permite que otras clases compartan ese comportamiento.
Ejemplo:
Ampliando el abanico de "responsabilidades"
Comentbamos anteriormente que no es fcil detectar las
responsabilidades, ya que generalmente tendemos a agruparlas. No
obstante, existen escenarios o casusticas en los que "se
permite" una cierta flexibilidad. Robert C. Martin expone un
ejemplo utilizando la interfaz Modem:
interface Modem
{
void dial(int pNumber);
void hangup();
void send(char[] data);
char[] receive();
}
En este ejemplo se detectan dos responsabilidades, relacionadas
con la gestin de la comunicacin (dial y hangup) y la
comunicacin de datos (send y receive). Efectivamente, cada una
de las funciones puede cambiar por diferentes motivos; sin
embargo, ambas funciones se llamarn desde distintos puntos de
la aplicacin y no existe una dependencia entre ellas, con lo
que no perderamos la cohesin del sistema.

conclusion

Pensemos siempre en el ciclo de vida de una aplicacin, y no
nicamente en su diseo y desarrollo.
Toda aplicacin sufre modificaciones a causa de cambios en los
requisitos o arreglo de fallos existentes, y el equipo de
desarrollo puede variar; si a ello le sumamos que el cdigo es
poco mantenible, los costes de mantenimiento se dispararn, y
cualquier modificacin se presentar como una causa potencial de
errores en entidades relacionadas dentro del sistema.
Recomendaciones
hay que incluir la clase GUI en la aplicacin de clculos
matemticos, a pesar de que esta aplicacin no muestra
informacin por pantalla.
posibles cambios relacionados con la interfaz grfica harn que
deba recompilarse, se deban volver a realizar las pruebas y
vuelva a desplegarse la aplicacin de clculos matemticos.