El código funciona, pero ¿por qué al abrir un archivo para cambiar una función hay que modificar cosas por todas partes?
Cambias el color de un botón y la lógica de pago se rompe. A todos nos ha pasado alguna vez.
Los conceptos que explican esta causa con dos palabras son el acoplamiento y la cohesión.
Cuanto menor sea el acoplamiento, mejor; cuanto mayor sea la cohesión, mejor. Gran parte del buen diseño empieza con esta frase.
En este artículo explico qué significan exactamente ambos conceptos, por qué se consideran las raíces de los principios de diseño de software y cómo aplicarlos al código real, a partir de mi experiencia.
Empecemos por los puntos clave.
- Acoplamiento: cuánto se entrelazan los módulos → cuanto menor, mejor
- Cohesión: cuánto se centra el código de un módulo en una sola tarea → cuanto mayor, mejor
- Estos dos conceptos sustentan principios conocidos como SOLID y los patrones de diseño.
- El objetivo es uno: código fácil de modificar y sustituir.
Acoplamiento y cohesión: ¿qué son exactamente?
Si resumimos primero ambos conceptos en una frase, sería así.
El acoplamiento describe la relación entre módulos, mientras que la cohesión describe la unión interna de un módulo.
Como apuntan en direcciones opuestas, es fácil confundirlos. Yo los memorizo así.
El acoplamiento es la «distancia con el exterior»; la cohesión, la «unidad interior».
Con un acoplamiento alto, corregir A arrastra también a B y C. Como fichas de dominó.
Con una cohesión baja, la lógica de pago, el envío de correos y el registro de logs se mezclan en una clase. Solo por el nombre no se sabe qué hace.
Un buen diseño lleva ambos conceptos en direcciones opuestas: débil por fuera, sólido por dentro.
¿Por qué son las «raíces» de los principios de diseño?
El acoplamiento y la cohesión se formalizaron por primera vez en la teoría del diseño estructurado de los años setenta. Se atribuyen a Larry Constantine.
Siguen siendo válidos casi medio siglo después porque expresan fundamentos independientes de cualquier lenguaje o moda.
Al analizar los principios conocidos, todos terminan convergiendo aquí.
| Principio · Patrón | Lo que realmente quiere decir |
|---|---|
| Principio de responsabilidad única (SRP) | Aumenta la cohesión |
| Principio de inversión de dependencias (DIP) | Reduce el acoplamiento |
| Principio de segregación de interfaces (ISP) | Rompe el acoplamiento innecesario |
| La mayoría de los patrones de diseño | Bajo acoplamiento + alta cohesión |
¿Lo ves? Los nombres cambian, pero la raíz es una sola.
Al aprender un principio o patrón nuevo, primero pregunto: «¿Busca reducir el acoplamiento o aumentar la cohesión?». Así entiendo la mitad.
¿Cómo reducir el acoplamiento? Veámoslo con código.
Como explicarlo solo con palabras puede resultar abstracto, veamos un ejemplo breve.
El código siguiente tiene un acoplamiento alto. La clase Order conoce directamente a un proveedor de pagos concreto.
class Order {
let pay = KakaoPay() // Acoplado directamente a Kakao Pay
func checkout() {
pay.send() // Para cambiar a otro método de pago hay que desmontar esto
}
}En cuanto cambias el proveedor a Toss, tienes que abrir Order y modificarlo. Este es el ejemplo típico de un acoplamiento alto.
Ahora vamos a crear distancia mediante un protocolo.
class Order {
let pay: Payment // 'Depende solo del contrato de «pago»
init(pay: Payment) { self.pay = pay }
func checkout() { pay.send() } // No importa qué implementación llegue
}Ahora Order no se preocupa por qué proveedor de pagos llegue. Solo hay que sustituir la implementación.
Después de hacer este cambio en producción, casi no tuve que tocar el código existente cuando pidieron añadir proveedores de pago. Ese es el poder del bajo acoplamiento.
¿Cómo se aumenta la cohesión?
La cohesión se evalúa preguntando si el módulo hace exactamente una sola cosa.
Mi criterio es simple: si al mencionar el nombre de una clase aparecen naturalmente todos sus métodos, tiene una cohesión alta.
Por ejemplo, encontrar lo siguiente mezclado en UserService es una señal de alerta.
- Procesamiento del registro de usuarios (responsabilidad principal)
- Envío de correos de marketing (trabajo ajeno)
- Generación de informes CSV (otro trabajo ajeno)
Es como si tareas sin relación vivieran de alquiler en la misma casa.
En ese caso, asigna una habitación propia al correo con EmailSender y otra a los informes con ReportGenerator.
Así ya no tendrás que abrir UserService para modificar la lógica de correo. El alcance del cambio se reduce.
El bajo acoplamiento y la alta cohesión apuntan a lo mismo: impedir que los cambios se propaguen.
Preguntas frecuentes (Q&A)
P. Entre acoplamiento y cohesión, ¿qué debería priorizar?
Recomiendo empezar por la cohesión. Al dividir los módulos para que cada uno se concentre en una sola responsabilidad, el acoplamiento suele ordenarse de forma natural.
P. ¿Es siempre mejor tener un acoplamiento de cero?
No. Si los módulos no están conectados en absoluto, el programa no puede funcionar. El objetivo no es cero, sino «solo lo necesario y de forma flexible».
P. ¿Debo diseñarlo todo perfectamente desde el principio?
No hace falta. Yo también hago que funcione primero y, cuando modificarlo empieza a doler, voy eliminando acoplamiento y aumentando cohesión. La refactorización es un proceso iterativo.
El acoplamiento y la cohesión no son tecnologías novedosas y llamativas, sino hábitos comunes de quienes escriben código que perdura.
En el código de hoy, pregúntate una vez: «Si cambio esto, ¿hasta dónde llegará el impacto?». Al repetir la pregunta, tu criterio de diseño crecerá rápidamente. ¡Ánimo!