Principio de responsabilidad única
Dentro del paradigma de desarrollo de software orientado a objetos existe el Principio de responsabilidad única, que se refiere a la delimitación de responsabilidades de una clase. El principio es bastante simple (al menos en la teoría) e inttuitivo y enuncia que una clase únicamente debe tener una razón para modificar su estado.
Responsabilidad única es un principio fundamentado y reforzador del concepto de cohesión toda vez que una clase con una sola responsabilidad (razón del cambio) cumple por consiguiente con una alta cohesión.
Y como en toda clase con alta cohesión ganamos en varios aspectos como en la curva de aprendizaje y el soporte ya que al integrar desarrolladores nuevos o requerir modificaciones sólo se debe comprender la responsabilidad que motiva al cambio de estado para poder dar el mantenimiento requerido. También ganamos en desacoplamiento y tiempo de pruebas ya que al tener una sóla responsabilidad nuestra clase puede ser sometida a pruebas unitarias más sencillas y controladas.
Para ejemplificar el principio imaginemos el panel de instrumentos de un automóvil específicamente velocímetro. La responsabilidad del velocímetro es informar cuando existe un cambio en la velocidad del auto. El velocímetro no mide los kilómetros recorridos para eso está el odómetro, tampoco mide el tiempo transcurrido para eso está el reloj, ni siquiera calcula la velodidad del auto para eso está la computadora, solamente informa la velocidad actual del auto a través de un display o de una manecilla, por otro lado el panel de instrumentos tiene la responsabilidad de mostrar el conjunto de instrumentos que contiene. Y esa es la escencia del Principio de responsabilidad única hemos visto que cada instrumento cumple con una responsabilidad específica.
En la práctica no suele ser tan sencillo identificar y delimitar la responsabilidad específica que debe tener una clase, pues para ello intervienen una serie de factores, principalmente debemos tener el conocimiento detallado del funcionamiento de la aplicación, también afecta la experiencia del desarrollador y del equipo de trabajo.
Una recomendación es la práctica de la refactorización busca de motivadores o razones de cambio en el estado de nuestro código, si tenemos por ejemplo métodos privados que realizan cálculos, llamadas externas, etc, son candidatos a ser extraídos hacia una nueva clase cuya responsabilidad única será realizar el cálculo o la llamada externa.
