1076. Identidad de la lección
1077. Objetivo de aprendizaje
Al terminar esta lección, podrás clasificar el riesgo principal de acoplamiento en una dependencia entre sistemas de juego y justificar la clasificación con un cambio concreto que podría verse afectado.
1078. Por qué importa
Un sistema puede parecer pequeño y aun así resultar caro de modificar cuando varias partes dependen de sus detalles. En un flujo de trabajo asistido por IA, el código generado puede conservar una dependencia sin hacer visible su coste. Nombrar el tipo de acoplamiento te proporciona una forma práctica de inspeccionar la dependencia antes de pedir a la IA que la modifique. El objetivo no es eliminar toda dependencia, sino reconocer cuál vuelve arriesgado el cambio propuesto.
1079. Conocimientos previos
Debes poder identificar una regla de juego y separar una regla ajustable del código que la ejecuta. Esta lección se apoya en 3.4 L2 — Volver declarativa una regla ajustable, especialmente en la idea de una frontera clara de configuración y una validación explícita.
1080. Concepto central
El acoplamiento es una dependencia que genera un coste de cambio. La pregunta importante no es solo si dos partes se comunican. Es esta: ¿qué debe saber una parte de la otra, qué debe poseer, qué debe ocurrir antes o qué datos debe recibir para que el sistema funcione?
Usa estas cuatro categorías:
| Tipo de acoplamiento | Señal de dependencia | Riesgo habitual al cambiar |
|---|---|---|
| Acoplamiento de conocimiento | Un sistema conoce detalles de la estructura interna o de las decisiones de otro. | Un cambio interno se propaga a los consumidores o deja supuestos duplicados. |
| Acoplamiento de ownership | Varias partes comparten la responsabilidad de crear, modificar o decidir sobre el mismo estado. | No queda claro quién puede modificar el estado ni qué efectos deben actualizarse. |
| Acoplamiento temporal | Una operación debe ocurrir antes que otra, aunque ese orden no sea evidente en la interfaz. | Reordenar, omitir o ejecutar de forma asíncrona un paso rompe el comportamiento. |
| Acoplamiento de datos | Una parte depende de la forma, el significado o la integridad de los datos que recibe. | Renombrar un campo, cambiar un tipo, omitir un valor o alterar su significado rompe consumidores. |
Las categorías pueden solaparse. Clasifica el riesgo principal preguntando qué dependencia haría más peligroso el cambio que tienes previsto.
1081. Modelo mental
Usa el análisis C-O-T-D:
- Conocimiento: ¿Este código necesita conocer los detalles internos de otro sistema?
- Ownership: ¿Quién crea, modifica y valida el estado importante?
- Tiempo: ¿Qué debe ocurrir primero y dónde se garantiza ese orden?
- Datos: ¿Qué campos, formas y significados deben seguir siendo compatibles?
Después completa esta frase:
«Cambiar [objetivo] es arriesgado porque [parte dependiente] se apoya en su [conocimiento / ownership / tiempo / datos]».
La frase obliga a formular una afirmación sobre la dependencia en lugar de usar una expresión vaga como «estos sistemas están muy conectados».
1082. Ejemplo concreto
Imagina un sistema de recompensas de puntos de control con estas responsabilidades:
CheckpointRuledeclara la cantidad de la recompensa y si el punto de control es válido.CheckpointControllerdetecta la finalización.RewardServiceconcede la recompensa y registra el resultado.HUDmuestra la notificación de recompensa.
Considera estos cambios:
- El controlador lee un campo privado de
CheckpointRuleen lugar de llamar a una operación pública de validación. Es principalmente acoplamiento de conocimiento: el controlador depende de la representación interna de la regla. - Tanto el controlador como el servicio de recompensas pueden modificar directamente el total de progresión del jugador. Es principalmente acoplamiento de ownership: la responsabilidad sobre el mismo estado está compartida.
- El HUD debe inicializarse antes de que el servicio pueda conceder una recompensa porque el servicio llama directamente a un método del HUD durante la inicialización. Es principalmente acoplamiento temporal: existe un orden obligatorio fuera de un contrato claro.
- El servicio envía al HUD un resultado con los campos
amountycurrency, y un cambio renombraamountcomovaluesin actualizar al consumidor. Es principalmente acoplamiento de datos: el consumidor depende del contrato de datos.
Una misma funcionalidad puede contener los cuatro tipos. La clasificación consiste en identificar el riesgo dominante para el cambio que estás evaluando.
1083. Error habitual
Un error habitual es clasificar toda dependencia como acoplamiento de datos porque «un sistema pasa información a otro». Los datos intervienen en muchas interacciones, pero el riesgo principal puede ser distinto. Si el problema es un orden de ejecución oculto, clasifícalo como temporal. Si el problema es que dos propietarios modifican el mismo estado, es de ownership. Si el problema es que un consumidor depende de un detalle de implementación, es de conocimiento.
Otro error es tratar el acoplamiento como algo automáticamente negativo. Un contrato de datos estrecho y explícito puede ser una dependencia adecuada. El problema de diseño es un coste de cambio que no se ha examinado o que resulta innecesariamente alto.
1084. Práctica guiada
Para cada caso, elige el riesgo principal de acoplamiento y completa la frase usando el análisis C-O-T-D.
Caso A
RewardService actualiza playerProgression, pero CheckpointController también resta de playerProgression cuando se reinicia un punto de control. Ambos sistemas pueden escribir el mismo valor.
Caso B
HUD da por hecho que RewardService.grant() siempre se ejecuta después de HUD.initialize(), pero ese requisito no aparece en el contrato del método. Una nueva secuencia de inicio llama primero a grant().
Caso C
CheckpointController lee CheckpointRule._internalThreshold y repite parte de la comparación de la regla en lugar de preguntarle si el punto de control es válido.
Caso D
RewardService envía { amount, currency } al HUD. Una refactorización cambia amount, que era un número entero de créditos, por una cadena formateada para mostrarla en pantalla, mientras el HUD todavía realiza cálculos numéricos.
Para cada caso, registra:
- la categoría principal: conocimiento, ownership, temporal o datos;
- las partes dependientes;
- el cambio ordinario que podría revelar el riesgo;
- un límite o una responsabilidad que haría más clara la dependencia.
La decisión importante es seleccionar la categoría principal aunque también aparezca otra. Explica por qué la categoría elegida representa el mayor coste de cambio para ese caso.
1085. Validación / evidencia
Tu evidencia será una tabla de acoplamiento de cuatro filas, una por caso. Cada fila debe incluir una categoría, una afirmación sobre la dependencia, un cambio plausible y una propuesta para aclarar el límite o la ownership.
Una respuesta sólida:
- nombra la dependencia en lugar de limitarse a nombrar dos sistemas;
- distingue la ownership del estado compartido de la transferencia de datos;
- identifica el orden oculto como acoplamiento temporal;
- identifica la exposición de detalles de implementación como acoplamiento de conocimiento;
- explica por qué la categoría elegida es el riesgo principal del caso.
Has cumplido el objetivo cuando otro desarrollador puede usar tu tabla para prever qué cambio probablemente exigirá editar varias partes coordinadamente.
1086. Ideas clave
- El acoplamiento se evalúa mejor por el coste de cambio que crea una dependencia.
- El acoplamiento de conocimiento expone detalles internos a través de un límite.
- El acoplamiento de ownership vuelve confusa o compartida la responsabilidad sobre el estado.
- El acoplamiento temporal oculta un orden obligatorio de operaciones.
- El acoplamiento de datos hace que los consumidores dependan de una forma o un significado de los datos.
1087. Próxima lección
Continúa con 3.5 L2 — Rechazar la reescritura del vecino.
1088. Comprobación
Responde estas preguntas por tu cuenta antes de leer las respuestas.
Un controlador lee el umbral privado de otro sistema y duplica su lógica de comparación. ¿Cuál es el riesgo principal de acoplamiento?
Mostrar respuesta y explicación
Respuesta: Acoplamiento de conocimiento
Por qué: El controlador depende de un detalle interno y duplica una decisión de implementación, por lo que un cambio dentro de la regla puede exigir cambios en el controlador.
Dos sistemas pueden modificar directamente el mismo total de progresión. ¿Qué riesgo de acoplamiento es más importante clasificar?
Mostrar respuesta y explicación
Respuesta: Acoplamiento de ownership
Por qué: El riesgo principal es que no quede clara la responsabilidad sobre el mismo estado. Varios escritores pueden producir reglas contradictorias y dificultar el razonamiento sobre un cambio.
Una operación de recompensa falla cuando se llama antes de otra operación de inicialización, pero ese orden no aparece en la interfaz. ¿De qué se trata principalmente?
Mostrar respuesta y explicación
Respuesta: Acoplamiento temporal
Por qué: El comportamiento depende de una secuencia no declarada: la inicialización debe ocurrir antes que la recompensa. Ese orden oculto es acoplamiento temporal.
Un consumidor se rompe porque un productor cambia el significado de un campo: pasa de una cantidad numérica a una cadena formateada para mostrar. ¿Cuál es el riesgo principal?
Mostrar respuesta y explicación
Respuesta: Acoplamiento de datos
Por qué: El consumidor depende del tipo y del significado semántico del campo. Cambiar ese contrato de datos rompe al consumidor aunque el orden y la ownership no cambien.