En algún momento nos ha tocado ver alguna parte de código dentro de algún software donde pensamos “¿Qué es esto?”, incluso cuando ese código fue realizado por nosotros mismos…
Spaghettis por doquier, un montón de funcionalidades juntas todo en un mismo archivo, clase o método haciéndolo difícil de entender..
En este post veremos el primero de los principios SOLID que corresponde a la letra “S” haciendo referencia al principio de responsabilidad única o en inglés “Single Responsibility Principle” el cual menciona que “Cada módulo del Software debe tener una y solo una razón para cambiar” donde un módulo se entiende como una clase o función que, en nuestro software quienes definen que y cómo se comporta la aplicación.
Estas clases deben representar correctamente alguna tarea en específico junto con su forma de hacerlo. Una clase con más de un propósito estaría agregando más complejidad innecesaria además de volver a nuestro software mas difícil de mantener y probar. El rendimiento de nuestra aplicación también puede verse afectado debido a ello, sin mencionar que cambios en el código pudieran afectar más sectores del software además de lo que pretendemos modificar.
Pero, ¿A qué nos referimos con responsabilidad?
Cuando hablamos de responsabilidad nos referimos a alguna actividad o tarea en particular, estas se encuentran separadas entre sí y no dependen ni se preocupan por lo que hace la otra y que además pudiera cambiar en el futuro por diversas razones (cambio en los requerimientos).
Cuando dos o más tareas están mezcladas en la misma clase, haciendo más difícil para el desarrollador realizar cambios, se dice que tenemos un acoplamiento elevado. Por el contrario, al tener esta lógica mejor separada de una forma más modular podemos decir que tenemos un bajo acoplamiento, lo cual vendría a ser uno de nuestros objetivos.
Cuando construimos nuestras clases, debemos revisar qué y qué no debería estar allí, si los elementos que están en una misma clase no tienen relación probablemente no pertenecen allí de manera que si por esta razón tenemos que enlazar clases entre sí, nos llevaría a tener más acoplamiento.
Como ejemplos de responsabilidades tenemos: el loggeo de la aplicación, el manejo de los datos, etc.
Tener nuestra aplicación un poco más modular, separando las responsabilidades nos ayuda a tener un producto más mantenible, que se puede probar de mejor manera y mucho más entendible.
Ten en cuenta que cada caso, cada software es diferente. Por lo que la implementación de este, y los demás principios no será la misma o incluso puede no existir, no es como que exista un reglamento que se deba seguir, si no más bien puedes verlo como una serie de recomendaciones que puedes ayudarte a obtener software de mejor calidad y su la manera en que se implementa queda sujeta a cada desarrollador.