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.