5/6/2018 El Principio de la responsabilidad individual - slidepdf.com

http://slidepdf.com/reader/full/el-principio-de-la-responsabilidad-individual 1/5

 

SRP: El principio de responsabilidad individual Nunca debe haber más de una razón para que una clase cambie.

Considere un juego de bolos. Para su desarrollo una clase Game tiene que manejar do

responsabilidades separadas. Estos son el seguimiento del frame actual y el cálculo de

puntuación. Para lograr esto, estas dos responsabilidades tienen que ser separadas en dos clase

La clase Game queda con la responsabilidad de realizar un seguimiento de los frames d

 juego, y la clase Scorer tiene la responsabilidad de calcular la puntuación.

¿Por qué era importante separar estas dos responsabilidades en clases separadas? Debido a qu

cada responsabilidad es un eje de cambio. Cuando los requerimientos cambien, ese cambio s

manifestará a través de un cambio de responsabilidad entre las clases.

Si una clase supone más de una responsabilidad, entonces habrá más de una razón para qu

cambie. Si una clase tiene más de una responsabilidad, entonces las responsabilidades s

acoplan.

Los cambios en una responsabilidad pueden afectar o inhibir la capacidad de la clase par

cumplir con las demás responsabilidades. Este tipo de acoplamiento conduce a diseños frágile

que se rompen de forma inesperada cuando se cambia.

5/6/2018 El Principio de la responsabilidad individual - slidepdf.com

http://slidepdf.com/reader/full/el-principio-de-la-responsabilidad-individual 2/5

 

Por ejemplo, considere el diseño en la Figura 9-1. La clase Rectangle tiene dos métodos qu

se muestran. Uno dibuja el rectángulo en la pantalla, el otro calcula el área del rectángulo.

Dos aplicaciones diferentes utilizan la clase Rectangle. Una aplicación hace geometr

computacional. Utiliza la clase Rectangle para realizar operaciones matemáticas sobre l

figuras geométricas. Nunca dibuja el rectángulo en la pantalla. La otra aplicación es de carácte

gráfico. También puede hacer un poco de geometría computacional, pero sin duda dibuja

rectángulo en la pantalla.

Este diseño viola la SRP. La clase Rectangle tiene dos responsabilidades. La primeresponsabilidad es proporcionar un modelo matemático de la geometría de un rectángulo. L

segunda responsabilidad es hacer que el rectángulo se renderice en una interfaz gráfica d

usuario.

La violación de SRP causa varios problemas desagradables. En primer lugar, debe incluir

interfaz gráfica de usuario en la aplicación de geometría computacional. Si se tratara de un

aplicación C + +, la interfaz gráfica de usuario tendría que estar enlazada, consumiendo tiemp

de enlace, tiempo de compilación, y footprint de memoria. En una aplicación Java, los archivo

.class para la interfaz gráfica de usuario tendrían que ser desplegados en la plataforma d

destino.

En segundo lugar, si un cambio en el GraphicalApplication hace que el rectángu

cambie por alguna razón, ese cambio puede obligar a reconstruir, volver a probar, y volver implementar el ComputationalGeometryApplication. Si nos olvidamos de hac

esto, la aplicación se puede romper de forma impredecible.

Un mejor diseño es separar las dos responsabilidades en dos clases completamente diferente

como se muestra en la Figura 9.2. Este diseño mueve las partes cómputacionales de la clas

5/6/2018 El Principio de la responsabilidad individual - slidepdf.com

http://slidepdf.com/reader/full/el-principio-de-la-responsabilidad-individual 3/5

 

Rectangle en la clase GeometricRectangle. Ahora los cambios realizados en

forma como los rectángulos son renderizados no pueden afectar a

ComputationalGeometryApplication.

¿Qué es una responsabilidad?

En el contexto del principio de responsabilidad individual (SRP) se define la responsabilida

como "una razón para el cambio." Si usted puede pensar en más de un motivo para el cambio d

una clase, entonces esa clase tiene más de una responsabilidad. Esto es a veces difícil de ve

Estamos acostumbrados a pensar en responsabilidad por grupos. Por ejemplo, considere

interfaz de módem en el Listing 9-1. La mayoría de nosotros estará de acuerdo en que es

interfaz parece perfectamente razonable. Las cuatro funciones que declara son sin duda la

funciones pertenecientes a un módem.

5/6/2018 El Principio de la responsabilidad individual - slidepdf.com

http://slidepdf.com/reader/full/el-principio-de-la-responsabilidad-individual 4/5

 

Sin embargo, aquí se muestran dos responsabilidades. La primera responsabilidad es la gestió

de la conexión. La segunda es la comunicación de datos. Las funciones dial  y hangu

gestionan la conexión del módem, mientras que las funciones send y recv comunican l

datos.

En este caso deberían separarse estas dos responsabilidades? Es casi seguro que sí deberían. Lo

dos conjuntos de funciones no tienen casi nada en común. Sin duda van a cambiar por diferent

razones. Por otra parte, se llamarán desde módulos completamente diferentes dentro de la

aplicaciones que los utilizan. Esos módulos pueden cambiar por razones diferentes también.

Por lo tanto el diseño en la Figura 9-3 es, probablemente, mejor. Separa las dos funciones en do

interfaces separadas. Esto, al menos, reduce el acoplamiento de las dos responsabilidades en la

aplicaciones cliente.

Sin embargo, observe que se han reacoplado las dos responsabilidades en una clase únic

ModemImplementation. Esto no es deseable, pero puede que sea necesario. A menud

hay razones, que tienen que ver con los detalles del hardware o sistema operativo, que no

5/6/2018 El Principio de la responsabilidad individual - slidepdf.com

http://slidepdf.com/reader/full/el-principio-de-la-responsabilidad-individual 5/5

 

obligan a acoplar cosas que preferiríamos no acoplar. Sin embargo, mediante la separación d

sus interfaces, se han desacoplado los conceptos en cuanto al resto de la aplicación se refiere.

Podemos ver la clase ModemImplementation es una chapuza, o una verruga en

diseño, sin embargo, observe que todas las relaciones de dependencia fluyen lejos de ésta. Nadi

necesita depender de esta clase.

Nadie, excepto main, necesita saber que existe (#ForeverAlone). Así, hemos puesto el bit fe

detrás de una valla. Esa verruga no tiene por qué filtrarse y contaminar el resto de la aplicación.

Conclusión

El SRP es uno de los principios más sencillos, y uno de los más difíciles de acertar. Conjugar la

responsabilidades es algo que hacemos naturalmente. Encontrar y separar las responsabilidad

de unos a otros es de lo que el diseño de software trata en realidad.

 Adaptación del artícul

SRP: The Single Responsability Princip

Martin, Robert

Object Mentor, 199