SRP – Principio de responsabilidad simple

Cómo comente en el post anterior, la idea es ir desarrollando cada uno de los principios S.O.L.I.D. un poco más en profundidad. El primero que vamos a ver, es el principio SRP (Principio de responsabilidad simple o Single Responsability Principle).

Básicamente los que nos dice este principio es que “una clase debe tener una, y solo una razón para cambiar“.

Qué significa esto?

Bajo el principio SRP, una razón es una responsabilidad, y una clase debería tener solamente una responsabilidad. En caso contrario, deberíamos delegar estas responsabilidades a nuevas clases.

Vamos a ver un ejemplo bien sencillo que nos va a ayudar a entender un poco mejor de qué se trata todo esto.

Supongamos que estamos trabajando en nuestra versión del juego PACMAN. Una de las primeras cosas que podríamos hacer, es crear una clase que represente los personajes del juego. La clase Personaje, tendría un atributo que representa la posición actual del personaje en el escenario y una acción que le permita avanzar de posición siempre que sea posible:

public abstract class Personaje
{
    public Posicion Posicion { get; set; }
    public void AvanzarCasillero(Posicion nuevaPosicion){}
}

Otra función que debería cumplir es la de comer otros personajes, por ejemplo Pacman puede comer fantasmas (siempre y cuando coma la píldora grande), en tanto que los fantasmas tienen como objetivo comerse a Pacman. Además de comer otros personajes, Pacman puede comer píldoras. Por lo tanto, todas estas acciones deberíamos incluirlas también:

public abstract class Personaje
{
   public Posicion Posicion { get; set; }
   public void AvanzarCasillero(Posicion nuevaPosicion){ }
   public void ComerPersonaje(Personaje personaje){ }
   public void ComerPildora(Pildora pildora) { }
 }

Cómo ya nos habremos dado cuenta, podemos ver que la clase Personaje tiene más de una razón para el cambio, ya que “comer píldoras” es responsabilidad únicamente de Pacman, y no del Fantasma.

Para aislar el método que está provocando “más de una razón para el cambio”, deberíamos crear las clases Pacman y Fantasma y delegar las responsabilidades que correspondan:

public abstract class Personaje
{
    public Posicion Posicion { get; set; }
    public void AvanzarCasillero(Posicion nuevaPosicion){ }
    public void ComerPersonaje(Personaje personaje){ }
}

public class Pacman : Personaje
{
    public void ComerPildora(Pildora pildora){ }
}

public class Fantasma : Personaje
{
}

De esta forma, tenemos bien definidas las responsabilidades de cada clase y ya no tenemos razones (al menos por ahora) para cambiarlas.

Beneficios de aplicar este principio:

  • Código más fácil de escribir y de entender.
  • Menos propenso a errores, ya que cada clase tiene una única responsabilidad bien definida
  • Facilita las tareas de testing : tenemos bien definido que debemos testear en cada clase.
  • Facilita las tareas de mantenimientos
  • Hace que nuestro código sea más robusto y extensible.

Como desventajas podríamos comentar que no siempre es muy simple asociar una única responsabilidad a una clase. También la “exageración” de aplicar este principio, podría llevarnos al extreme de llegar a tener una clase por método!… lo que nos llevaría a tener una gran cantidad de clases sin sentido y que solo nos confundirían.

Anuncios

6 comentarios en “SRP – Principio de responsabilidad simple

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s