Desgraciadamente, puede que cada día tengas que enfrentarte a algo así: solucionas un error en un sitio del software, o cambias algo, y deja de funcionar algo de otro módulo que tu creías que no estaba relacionado con él. Pero vaya, misteriosamente parece que sí lo estaba.
Una de las posibles causas de esto puede ser que los módulos del software estén altamente acoplados entre sí, y por no controlarlo, no te des ni cuenta de ello.
Tanto si has padecido esto, y no sabías que podía ser por acoplamiento, o te suena de algo pero nunca has llegado a entender qué es…Este post es para ti.
¿Qué es eso del acoplamiento?
El acoplamiento es el grado en el que los módulos del software dependen unos de otros (de hecho, ya hablé algo sobre acoplamiento en el post de la Ley de Demeter).
Cuando por ejemplo una clase A, usa una clase B, entonces se dice que A depende de B. En este caso, A no puede realizar su trabajo sin B, y A no puede ser reutilizada sin tener que reutilizar B. Entonces, como A depende de B, se dice que hay acoplamiento.
Además, hay que tener en cuenta que las dependencias o el acoplamiento son direccionales, es decir, que A dependa de B, no significa que B también dependa de A.
En resumen, si para cambiar un módulo en un programa tenemos que cambiar otro módulo, entonces hay acoplamiento entre ellos.
El acoplamiento puede aparecer bajo varias formas. Por ejemplo, si hay código repetido esparcido entre los módulos, también habrá un cierto acoplamiento, porque cambiar un fragmento de código repetido implica cambiarlo en todos los módulos que aparece.
Incluso puede que haya dependencias entre módulos y no nos demos cuenta de ello.
Pero el acoplamiento también ocurre cuando el código de un módulo utiliza código de otro módulo, bien porque llama a un método, o accede a sus datos.
Por ello, como tal, el acoplamiento no es algo que debas evitar a toda costa.
Porque aunque dividamos nuestro programa en módulos, esos módulos tendrán que interactuar entre sí de alguna manera (si no tendríamos distintos programas independientes) y tendremos algo de acoplamiento entre ellos.
Hay distintos tipos y lo que es más importante, grados de acoplamiento.
Lo que es malo, y puede que lo estés padeciendo, es tener un acoplamiento alto, fuerte, entre los módulos.
Y peor si es incontrolado, es decir, si no sabes claramente qué módulos dependen de otros módulos.
Por eso, lo ideal es que los módulos software tengan poco acoplamiento y dependan lo menos posible de otros módulos distintos a él.
¿Por qué? Perseguimos un bajo acoplamiento software para que un cambio en un módulo no afecte a otro módulo sin que te enteres. Además el código será más fácil de reutilizar, ya que no tendrás que incluir, que arrastrar las dependencias de otras clases que lleve consigo.
Por lo tanto, un código menor acoplado será más mantenible y más fácil de probar. De hecho, módulos altamente acoplados dificultan realizar pruebas unitarias (aquí tienes un resumen de las distintas pruebas que hay, entre ellas las unitarias)
Así que debemos mantener el acoplamiento controlado, sabiendo realmente qué clases dependen unas de otras, qué relaciones hay entre ellas, para ser conscientes del impacto que puede tener realizar un cambio en el software.
Y de la mano del acoplamiento, suele venir otro concepto que también es un incomprendido, y da lugar a confusión. La cohesión.
Cohesión
Decimos que algo tiene una alta cohesión, si tiene unos límites claros y todo lo que hace está contenido en un único sitio.
Permíteme que te ponga dos ejemplos del día a día (fuera del software), para que quede claro lo que significa cohesión.
Por ejemplo, un balón tendría una alta cohesión: tiene una forma definida, límites claros (es redondeado), y todo lo que implica el concepto balón está en un único sitio.
Por otra parte, Internet sería un ejemplo de algo con baja cohesión: es algo muy amplio y sus límites no están definidos. Detrás de Internet hay muchas redes de ordenadores, muchos dispositivos, distribuidos en distintos sitios y cada uno de ellos hace que Internet sea posible. 
Volviendo al software, una clase o un módulo tendría una alta cohesión si tiene una responsabilidad u objetivo claro, y toda la implementación de esa responsabilidad está localizada cerca o incluso en un único sitio.
Un ejemplo de alta cohesión en el software sería tener toda la lógica de nuestro programa relacionada con la escritura en la base de datos en una clase o un conjunto de clases en un módulo, en vez de que cada clase individual implemente el acceso a la base de datos.
Nuevamente, programar de esta manera hace que el código sea más mantenible, más fácil de entender y reutilizable.
Además reduce los efectos de cambiar una parte del código afecte al resto del sistema, ya que el código que realiza esa funcionalidad está localizado y no distribuido a lo largo de varias clases.
Umm…¿entonces cohesión y acoplamiento están relacionados?
Lo cierto es que sí, estos conceptos están muy relacionados.
Lo que suele pasar es que si escribes módulos con responsabilidades claras y bien definidas y con sus implementaciones localizadas en un sitio (alta cohesión), será probable que el acoplamiento de esas clases con el resto del sistema sea menor.
Además, si reducimos acoplamiento, normalmente aumentaremos la cohesión de los módulos.
Terminando…
Espero que te hayan quedado un poco más claro estos dos conceptos, porque son muy importantes para el día a día.
Así que no se te olvide esta frase típica que se dice con respecto a este tema:
“Diseña el código de tal manera que éste tenga una alta cohesión y un bajo acoplamiento”.
Y otro consejo que te dejo yo. Ten controladas las dependencias que hay entre tus módulos, para conocer el impacto que supone realizar algún cambio. Si haces esto, seguro que lo agradecerás.
Si te pica el gusanillo, para ayudar a reducir el acoplamiento hay distintas técnicas y consideraciones: introducir abstracciones e interfaces, también está el principio de Inversion of Control, Inyección de Dependencias, métricas como LCOM y RFC etc.
Pero si me lo permites, eso ya será para un próximo post.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024
Con ganas de leer el próximo post. Una de más sencillas y clarificadoras explicaciones que he leído sobre cohesión y acoplamiento.
Hola ana. Queria consultarte si se puede eliminar totalmente el acoplamiento entre clases y como se aria ya que escuche el tema de clases genéricas, no se si estaria relacionado.