Coupling has a change cost

1076. Lesson identity

Module

3.5 — Coupling

Lesson

1 — Coupling has a change cost

Academic type

Systems

Schema type

text

Order

1

Estimated time

30–45 minutes, including practice

1077. Learning objective

After this lesson, you can classify the main coupling risk in a game-system dependency and justify the classification with a specific change that could be affected.

1078. Why this matters

A system can look small and still be expensive to change when several parts depend on its details. In an AI-assisted workflow, generated code may preserve a dependency without making its cost visible. Naming the coupling type gives you a practical way to inspect the dependency before asking AI to modify it. The goal is not to eliminate every dependency; it is to recognize which dependency makes a proposed change risky.

1079. Prior knowledge

You should be able to identify a gameplay rule and separate a tunable rule from the code that executes it. This lesson builds on 3.4 L2 — Make a tunable rule declarative, especially the idea of a clear configuration boundary and explicit validation.

1080. Core concept

Coupling is a dependency that creates a change cost. The important question is not simply whether two parts communicate. The question is: what must one part know, own, happen before, or receive from the other for the system to work?

Use these four categories:

These categories can overlap. Classify the main risk by asking which dependency would make the intended change most dangerous.

1081. Mental model

Use the K-O-T-D scan:

1. Knowledge: Does this code need to know another system's internals?
2. Ownership: Who creates, mutates, and validates the important state?
3. Timing: What must happen first, and where is that order enforced?
4. Data: Which fields, shapes, and meanings must remain compatible?

Then complete this sentence:

“Changing [target] is risky because [dependent part] relies on its [knowledge / ownership / timing / data].”

The sentence forces a dependency claim instead of a vague statement such as “these systems are tightly connected.”

1082. Concrete example

Imagine a checkpoint reward system with these responsibilities:

• CheckpointRule declares the reward amount and whether the checkpoint is eligible.
• CheckpointController detects completion.
• RewardService grants the reward and records the result.
• HUD displays the reward notification.

Consider four changes:

1. The controller reads a private field inside CheckpointRule instead of calling a public eligibility operation. This is primarily knowledge coupling: the controller depends on the rule's internal representation.
2. Both the controller and the reward service can directly modify the player's progression total. This is primarily ownership coupling: responsibility for the same state is shared.
3. The HUD must be initialized before the reward service can grant a reward because the service directly calls a HUD method during initialization. This is primarily temporal coupling: a required order exists outside a clear contract.
4. The reward service sends a result object whose amount field is required by the HUD, and the field is renamed to value without changing the consumer. This is primarily data coupling: the consumer depends on the data contract.

The same feature can contain all four types. Classification is about identifying the dominant risk for the change you are considering.

1083. Common mistake

A common mistake is to classify every dependency as data coupling because “one system passes information to another.” Data is involved in many interactions, but the main risk may be different. If the problem is hidden execution order, classify temporal coupling. If the problem is two owners mutating the same state, classify ownership coupling. If the problem is a consumer relying on an internal implementation detail, classify knowledge coupling.

Another mistake is treating coupling as automatically bad. A declared, narrow data contract can be an appropriate dependency. The design problem is an unexamined or unnecessarily expensive change cost.

1084. Guided practice

For each case, choose the main coupling risk and complete the sentence using the K-O-T-D scan.

Case A

RewardService updates playerProgression, while CheckpointController also subtracts from playerProgression when a checkpoint is reset. Both systems can write the same value.

Case B

HUD assumes that RewardService.grant() always runs after HUD.initialize(), but that requirement is not represented in the method contract. A new startup sequence calls grant() first.

Case C

CheckpointController reads CheckpointRule._internalThreshold and reproduces part of the rule's comparison instead of asking the rule whether the checkpoint is eligible.

Case D

RewardService sends { amount, currency } to the HUD. A refactor changes amount from an integer number of credits to a formatted display string, while the HUD still performs numeric calculations.

For each case, record:

• the primary category: knowledge, ownership, temporal, or data;
• the dependent parts;
• the ordinary change that could expose the risk;
• one boundary or responsibility that would make the dependency clearer.

The meaningful decision is to select the primary category even when another category is also present. Explain why your selected category represents the largest change cost.

1085. Validation / evidence

Your evidence is a four-row coupling table with one row for each case. Each row must include a category, a dependency statement, a plausible change, and a proposed boundary or ownership clarification.

A strong response:

• names the dependency rather than merely naming two systems;
• distinguishes shared state ownership from data transfer;
• identifies hidden order as temporal coupling;
• identifies implementation-detail exposure as knowledge coupling;
• explains why the selected category is the main risk for that case.

You have met the objective when another developer could use your table to predict which change is likely to require coordinated edits.

1086. Key takeaways

• Coupling is best evaluated by the change cost created by a dependency.
• Knowledge coupling exposes internal details across a boundary.
• Ownership coupling makes responsibility for state unclear or shared.
• Temporal coupling hides a required order of operations.
• Data coupling makes consumers depend on a data shape or meaning.

1087. Next lesson

Continue to 3.5 L2 — Refuse the neighbor rewrite / Rechazar la reescritura del vecino.

1088. Knowledge check