SOLID – Principio de Resposanbilidad Única

SOLID – Principio de Resposanbilidad Única

Es posible que hayas visto en otros lugares la definicion de este principio como: «Una clase sólo debe tener una responsabilidad».

A pesar de que el anterior es un principio de diseño válido no es lo que, en palabras del teorizador de SOLID, el SRP (Single Responsability Principle) pretende.

Para Robert C. Martin, el principio de responsabilidad único es que un módulo sea responsable de uno y solo un actor.

Por ejemplo si tenemos una clase que representa un jugador de fútbol, esta no puede ser manejada por actores como el director deportivo, el presidente del club, el entrenador y el masajista a traves de métodos creados para ello en la clase Jugador, pues puede derivar en conflictos de código cruzado.

Imaginemos que tenemos una clase Jugador con tres métodos

  • recibirMasaje() efectuado por el masajista para los jugadores que rindan más
  • recibirFeedbackPositivo() llamado por el entrenador para aquellos jugadores que rindan más
  • getRendimiento() devuelve un valor usado para calcular los masajes y el feedback del entrenador

Por tanto tenemos dos actores de los cuales depende Jugador. Si modificamos el algoritmo de getRendimiento(), que en funcion de su salida modifica el tipo de feedback o la intensidad de masajes, el cambio en el cómputo de este rendimiento puede no satisfacer al resultado que se espera en ambos métodos.

Si el rendimiento en un momento dado se calcula con respecto al numero de kilómetros recorridos, pero luego el entrenador quiere que se compute con respecto a la media de goles en cada partido, se puede dar el caso de que el masajista, ajeno al cambio es este cómputo comience a tratar sólo a los delanteros y no a los defensas, provocando el desastre en el vestuario.

El principio indica que debemos separar el código del que dependen varios actores, de esta forma, cada actor podrá realizar su propio calculo de rendimiento, priorizando lo que desee cada uno para su cómputo a la hora de realizar una acción.

Ahora cada clase tiene un actor como máximo del que depende y la funcionalidad de estas clases tiene una lógica separada de todas las demás funcionalidades que proveen otros actores. Las clases Masaje y Feedback sólo tienen un motivo para cambiar el código fuente: que sus actores así lo consideren, mientras que antes la clase Jugador tenían dos motivos para cambiar su código en funcion de cómo se quería calcular el rendimiento.

Los principios SOLID

Los principios SOLID

SOLID es un acrónimo para una serie de principios definidos por Robert C. Martin, un famoso autor y arquitecto de software autor de varios libros que es posible que os suenen, como Clean Code, Clean Architecture o The Clean Coder, todos altamente recomendados para cualquier programador o trabajador del software.

En ellos se presentan una serie de principios que definimos como SOLID y que buscar la escalabilidad, claridad y escalamiento de todo el software que desarrollemos.

Estos cinco principios son los siguientes, respetando su nomenclatura inglesa:

En cada uno de los enlaces expuestos podreis encontrar más con más detalle en qué consiten cada uno de estos principios, en mi opinion absolutamente necesarios de comprender para la realizacion de un código que se pueda definir como profesional.