Principio de responsabilidad única

Oscar Galindo
febrero 1, 2016
Arquitectura de software, Tendencias tecnológicas
arquitectura de software, solid, SRP

Compartir esta publicación

Table of Contents

En la programación orientada a objetos existen cinco principios básicos (SOLID) que, bien aplicados, marcan la diferencia entre un buen y un mal diseño. La diferencia entre una aplicación fácil de mantener y una que no. La diferencia entre un buen desarrollador y uno que no lo es. En este articulo vamos a hablar más sobre el principio de responsabilidad unica.

Single Responsability Principle (Principio de responsabilidad unica )
Open/Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle

Vamos a empezar por el primero de todos, el principio de responsabilidad única, definido por Robert C. Martin en su libro Agile Software Development, Principles, Patterns, and Practices. Es un concepto muy simple de explicar, sin embargo, difícil de poner en práctica. Como su propio nombre indica, este principio habla de que una clase o módulo debe tener una única responsabilidad.

Dentro del contexto del SRP, la responsabilidad es definida como una razón para cambiar. Por tanto la frase de Robert C. Martin es una definición perfecta sobre qué es el principio de responsabilidad unica:

“A class should have only one reason to change”.

Cumpliendo este principio te aseguras que tu clase o módulo tiene una cohesión alta, lo que significa que tu clase no hace más de lo que debería hacer. En definitiva, una única razón para cambiar. Si, por lo contrario, construyes una clase con más de una responsabilidad, lo que estás haciendo es acoplar dichas responsabilidades, y esto conduce a un diseño frágil y difícil de mantener, con todo lo que ello conlleva.

Entrevista con Neal Ford sobre las métricas de la arquitectura del software

Ejemplo

En este simple ejemplo se puede ver una clase Rectángulo que tiene dos métodos: Area() que tiene la responsabilidad de devolver el área del rectángulo y otro método,
draw(), que tiene la responsabilidad de dibujar el rectángulo en sí.

En este diseño se puede apreciar que, si por cambios en la GUI, debemos modificar la clase Rectángulo, entonces estamos obligados a testear, de nuevo, la otra aplicación que ataca a la misma clase. La solución a este problema es dividir dicha clase en dos diferentes, de tal manera que cada clase tiene una única responsabilidad. Una será la responsable de calcular, y otra de pintar:

Hay que tener en cuenta que este principio desemboca en muchos otros matices y conceptos, ya no sólo los que entran dentro de SOLID, sino otros que se deben conocer y saber aplicar para conseguir una aplicación con un diseño sólido.