Indirection

“How to decouple objects so that low coupling is supported and reuse potential remains higher?” – Craig Larman

Assign the responsibility to an intermediate object to mediate between other components or services so that they are not directly coupled.

When to use

When two components need to interact but direct knowledge of each other would lead to rigid coupling.

Why it matters

Low Coupling: Components A and B don’t know each other; they only know the interface or the mediator.
Flexibility: You can replace one component without affecting the other.

Signs of Violation

Direct hard dependencies between major system layers (e.g., UI directly calls external API wrapper).
Hard to mock/test because X depends on Y directly.

Explanation

Problem

Direct connection is rigid. If X relies on Y, X is stuck with Y.

Solution

Put something in the middle. “All problems in computer science can be solved by another level of indirection” (David Wheeler).

Real world analogy

Adapters, Translators, Brokers. You don’t plug your phone directly into the nuclear power plant; you use a wall outlets and chargers (intermediate layers of indirection) to deliver power safely.

Pros and Cons

Pros	Cons
Decoupling Flexibility	Performance overhead Complexity (harder to trace execution flow)

Comparison

Adapter Pattern: Creates indirection to make incompatible interfaces work together.
Facade Pattern: Creates indirection to simplify a complex subsystem.
Proxy Pattern: Indirection for access control or lazy loading.