Composition usually means delegation. What is delegation in practice, what boilerplate and pitfalls does it bring, and what is the "self-problem"?

## What delegation is **Delegation** = object *A* receives a request and passes it to object *B* to fulfil, possibly adding behavior around it. *A* holds *B* (composition) rather than inheriting from it. It usually implements the same interface as *B*, so callers can't tell the difference. ``` interface Repo { fun load(id): Doc } class LoggingRepo(private val inner: Repo) : Repo { override fun load(id): Doc { log("load $id") return inner.load(id) // the delegation } } ``` This is the machinery behind: - **Decorator** — same interface, adds behavior, stackable (`Metrics(Caching(Logging(repo)))`). - **Proxy** — same interface, controls access (lazy load, remote call, permission check). - **Adapter** — *different* interface in, target interface out. - **Strategy** — the outer object delegates one decision to an injected collaborator. ## Cost 1 — boilerplate Wrapping a 30-method interface means 30 one-line forwarders that must stay in sync. Language and tooling answers: - **Kotlin**: `class LoggingRepo(private val inner: Repo) : Repo by inner { override fun load(id) = ... }` — the compiler generates all forwarders; you override only what you change. - **Go**: embedding a struct or interface promotes its methods automatically. - **Groovy**: `@Delegate`. **Lombok**: `@Delegate`. **C#**: source generators or `DispatchProxy`. - **Runtime dynamic proxies** (JDK `Proxy`, `InvocationHandler`; aspect frameworks) generate a wrapper at runtime — powerful, but you lose compile-time checking and stack traces get noisy. If the language gives you none of this, weigh the boilerplate honestly; for very wide interfaces, or when you truly need to intercept internal calls, inheritance may be pragmatic — with the fragility accepted knowingly. ## Cost 2 — the self-problem (the important one) With **inheritance**, `this` is one object. When base code calls `this.helper()`, dispatch finds the subclass override. Interception is total. With **delegation**, there are **two objects**. When the inner object calls its own `this.helper()`, `this` is the *inner* object — the wrapper is not in the picture and never sees the call. Concretely: you wrap a repository with caching. `repo.loadAll()` internally calls `this.load(id)` for each id. Your cache wraps the *outer* `load`, so those internal loads bypass the cache entirely. The behavior you thought you added is partial. This is the exact mirror image of the fragile base class problem: - Inheritance intercepts internal self-calls — sometimes *too much*, and the base can change them out from under you. - Composition intercepts nothing internal — sometimes *too little*, but you're immune to base refactors. Workarounds: design the inner type so cross-cutting concerns route through a delegate-aware seam (pass the outer object in, i.e. explicit "self" parameter — the technique sometimes called *consultation vs delegation*), split the inner type so no method calls its own siblings, or put the concern at a boundary (a facade/service layer) where all traffic must pass. ## Cost 3 — identity, equality, and type checks A wrapper is a distinct object: - `wrapper != inner` under reference equality; `equals` is whatever you write (forwarding `equals` breaks symmetry — `inner.equals(wrapper)` is usually false). - `instanceof ConcreteInner` / `is ConcreteInner` fails. Code that downcasts or switches on concrete types breaks when you introduce a wrapper — a good reason such code shouldn't exist. - Identity maps, caches keyed by object identity, `IdentityHashMap`, and serialization can see doubled or unexpected objects. - Frameworks that read annotations off the concrete class may not see them through a proxy. - Thread-safety and lifecycle: who closes the inner resource, the wrapper or the owner? Decide and document. ## Cost 4 — interface evolution When the delegated interface gains a method: - **hand-written** forwarders fail to compile → you're forced to decide (good); - **auto-generated** delegation (`by`, embedding) silently forwards the new method → your wrapper's cross-cutting concern silently doesn't apply to it (subtle). Neither is free; know which behavior your mechanism gives you. ## Cost 5 — debuggability Deep decorator stacks make traces long and make "which layer did this?" harder. Order matters semantically (retry-outside-cache behaves differently from cache-outside-retry) and is invisible at the call site — document the intended assembly in one place. ## When delegation clearly beats overriding - Adding behavior to a type you don't own (never subclass a third-party concrete class). - Behavior that should be composable and reorderable (metrics, retries, caching, auth). - Behavior that must change at runtime or be swapped in tests. - Wrapping to *narrow* an API (exposing 3 of 30 methods) — inheritance can only widen.