Single Responsibility Principle(SRP), Nunca debe haber más de una razón para que una clase cambie.

  • RSS
  • Add To My MSN
  • Add To Windows Live
  • Add To My Yahoo
  • Add To Google
Posted by Ehudes Garcia Friday, September 02, 2011 10:00:00 AM Categories: Arquitectura de Software Diseño de software Ingeniería de Software Metodologías ágiles Pruebas de software

Hombre Orquesta

Entre mas responsbilidades, mas dificultades

Este es el segundo post de una saga de 6 post acerca de los S.O.L.I.D. Principles. Ver post anterior.

No soy músico, pero estoy seguro que el hombre orquesta de la imágen tiene muchas limitaciones y complicaciones en sus interpretaciones, no se puede comparar con el campo de acción musical que tiene una orquesta donde cada hombre es responsable de tocar un solo instrumento.

Esto mismo aplica a las clases y componentes que desarrollamos, una clase "orquesta"(con muchas resonsabilidades) tiene muchas dificultades y origina muchos problemas, como por ejemplo: de mantenibilidad, de reusabilidad, de testeabilidad, creación de Side Effects, creación de Big Balls Of Mud, entre otros.

 

Unica Responsabilidad

 Una sola razón para cambiar

Comparanado este trompetista con nuestro hombre orquesta bajo la luz del principio SRP podemos concluir que:

Es mas especialista.(Cohesion)

Puede fácilmente trabajar en varias orquestas, el hombre orquesta es la orquesta.(Reusabilidad)

Siempre esperamos lo mismo de él, que toque la trompeta.(Reducción de Side effects)

Si en las interpretaciones de la orquesta algo está mal con la trompeta pues le pedimos que mejore o en últimas lo cambiamos,¿al hombre orquesta como lo cambiamos? se acaba la orquesta se acaba el negocio.(Mantenibilidad)

Dejando a un poco a una lado la analogía músical y entrando ya en lo grueso del principio SRP lo que debemos entender es que el significado de responsabilidad en el contexto de este principio es tener una sola razón para cambiar, tan simple como eso, lo que sucede es que aplicarlo no es tan simple, es subjetivo, porque no siempre es claro cual es esa única razón de cambio, lo que yo hago es partir las clases y las funciones tratando siempre de tener la cohesión y granularidad adecuada.

Una clase con muchas funciones y/o funciones muy grandes es una señal de que no se está alineado con el principio SRP, también cuando debes realizar Copy/Paste de una fracción de código de una función, porque reutilizar esa función invocando la clase no es debido por posibles Side Effects.

 

La gran sinfonia

La gran sinfonia

Un  orquesta sinfónica al igual que un Sistema se compone de grupos cohesionados de componentes mejor dicho de instrumentos, y estos grupos se componen de músicos escpecializados en un sólo instrumento y mas aún, responsables de tocar una sola partitura de cada pieza músical.

Un solo trompetista no puede ejecutar una Sinfonia, el hombre orquesta tampoco o con mucha dificultad lo lograría, entoces lo que debemos propender es por tener clases con las funciones necesarias y que estas a su vez sean "pequeñas", con una única razón para cambiar en la medidad de lo posible(no siempre es posible tener clases con una sola razón para cambiar) y orquestadas(aka arquitectadas o diseñadas) para componer un gran sistema, para interpreptar una gran Sinfonia.

 

Fuentes

http://avanet.org/de-los-principios-y-otras-virtudes.aspx

http://msdn.microsoft.com/es-co/magazine/cc546578.aspx

http://www.objectmentor.com/resources/articles/srp.pdf

 http://iamnotmyself.com/2009/02/03/s-o-l-i-d-by-example-single-responsibility-principal/

http://es.wikipedia.org/wiki/Filarm%C3%B3nica

 

Happy Coding

The Clean Coder, Because small things matter.

Comments

Friday, September 02, 2011 1:12:24 PM

re: Single Responsibility Principle(SRP), Nunca debe haber más de una razón para que una clase cambi

buen post 

Comments are closed on this post.
© 2009 - 2013 Avanet