Los cinco principios de diseño de software SOLID fueron reunidos por Robert Martin (@unclebobmartin) a partir de varias ideas y papers pre-existentes en la comunidad. En estos artículos los revisaremos uno a uno con la interpretación desde mi experiencia con ellos y cómo han afectado mi forma de programar.

Todos los principios los puedes ver en el índice: http://www.davidlaym.com/2015/05/solid-resumen-de-los-principios

Principio de responsabilidad única

La S en SOLID es por “Single responsability principle” que puede ser traducido como principio de responsabilidad única. Este principio es uno de los más difíciles de explicar, pero también uno de los más aplicables en el día a día.

La explicación original indica: “Una clase debe tener un solo motivo para cambiar”. Inicialmente me costó mucho entender esta frase, porque pensaba que era más complicado de lo que parecía, y en realidad, es tan simple como parece. Un archivo, que contiene una clase, debe tener un solo motivo para ser modificado, es decir, para cambiar un método o una variable dentro de la clase.

Una responsabilidad, es un motivo para el cambio. Si una clase tiene la responsabilidad de persistir una entidad a la base de datos, quiere decir que el único motivo para que alguien quiera cambiarla, es que también haya cambiado la forma de persistir la entidad. Si una clase tiene muchas responsabilidades, habrán muchos motivos para que alguien quiera modificar la clase en distintos momentos.

¿Porqué es malo tener una clase con muchas responsabilidades? Por varios motivos. El primero y el más importante,  es el acople entre las responsabilidades. Si una clase tiene más de una responsabilidad, inevitablemente van a haber repercusiones en las otras responsabilidades al realizar cambios en una. ¿Cuánto les ha pasado que tienen mucho miedo de modificar una clase muy grande porque pueden estropear alguna de las otras funcionalidades? Diseñar clases con varias responsabilidades genera software frágil que se comporta de maneras inesperadas

Otro de los motivos, aunque secundario, es que al mantener las responsabilidades separadas en clases independientes, es más fácil rastrear los cambios en el sistema de control de versiones. También es más sencillo colocar nombres significativos a las clases, en ves de tener un montón de “Managers” y “Helpers” que nadie sabe bien que hacen.

Sin embargo, detectar las posibles responsabilidades que una clase tenga no es siempre sencillo, debido a que solemos pensar en las responsabilidades de manera agrupada, por ejemplo, dibujar un elemento gráfico para alguien puede parecer una sola responsabilidad, pero fácilmente se pueden separar los cálculos matemáticos de la manipulación de la API gráfica.

En el otro lado también hay dificultades, intentando no separar innecesariamente responsabilidades que no son un problema. Por ejemplo, si detectas dos responsabilidades distintas en una clase, pero estas siempre cambian juntas, entonces no tiene sentido separarlas. Un ejemplo de este comportamiento sería, por ejemplo, la responsabilidad de almacenar una entidad modificada en base de datos y retornar de vuelta el objeto modificado (suponiendo que no se usa un ORM que lo hace por nosotros). En este caso, si bien son dos operaciones distintas que podrían ser separadas, cada vez que se cambie la forma de persistir la entidad, la forma de leer la entidad también será alterada.