What is the Message Chains code smell, how does it relate to the Law of Demeter, and why can "fixing" it with Hide Delegate produce the Middle Man smell?

## Message Chains **Definition.** A client navigates a sequence of objects to reach the one it actually needs: ``` city = order.getCustomer().getAddress().getCity().getName() ``` **Why it hurts.** - **Structural coupling.** The client depends not just on `Order` but on `Customer`, `Address`, and `City` and on how they are linked. Any change to that chain — inserting a `BillingProfile`, making address a collection — breaks every client. - **Duplication.** The same navigation is copy-pasted across many callers, so the change cost multiplies. - **Null/absence handling.** Each hop can be absent, so real code grows guards at every link, or crashes. - **Hidden intent.** The chain says *how to get there*, never *what is wanted*. **Refactorings.** 1. **Hide Delegate** — the first object exposes what the caller wants: `order.customerCity()`. The client now knows one type instead of four. 2. **Extract Function + Move Function** — better still, move the *computation* to the object that owns the data, so nothing needs fetching at all (Tell, Don't Ask). 3. **Pass what is needed.** If the callee only wants a city name, pass the city name rather than the whole graph root. ## The Law of Demeter Proposed by Karl Lieberherr and colleagues (Northeastern University, 1987) as the *principle of least knowledge*. The object-form rule: a method `m` of object `O` may only invoke methods of - `O` itself, - `m`'s parameters, - objects `m` creates, - `O`'s direct component objects (fields), - (commonly added) globals/statics accessible to `O`. It may **not** invoke methods on objects *returned* by any of those calls. Hence the nickname "don't talk to strangers" and the crude test "one dot" — crude because the dot count is not what matters. **Important qualifications.** - **It is a heuristic, not a law.** Blindly enforcing it inflates interfaces with pass-through methods (exactly the Middle Man risk) and can *increase* total coupling. - **Data structures are exempt in spirit.** Navigating a plain data record (`config.server.port`), a builder (`b.name(x).age(y).build()`), or a functional pipeline (`items.filter(...).map(...).toList()`) is not the smell: builders and pipelines return *the same or a new value*, not a deeper object you are coupling to. The smell concerns *behaviour-bearing objects whose internal structure you are traversing*. - **The pain is real where the graph is unstable.** Chains through stable, published value types are cheap; chains through volatile internal domain structure are expensive. ## Middle Man — the over-correction **Definition.** A class whose methods mostly just delegate to another object, adding no behaviour, no policy, no translation. Hiding delegates is good in moderation: each hidden hop buys the client independence from one intermediate type. But if `Order` gains `customerCity()`, `customerPostcode()`, `customerCountry()`, `customerVatNumber()` … it has become a pass-through façade whose interface grows every time the client needs a new field, and every added method is a change in two places. **Refactoring: Remove Middle Man** — delete the forwarders and let the client obtain and use the delegate directly (`order.customer().city()`), or **Replace Delegation with Inheritance/Composition** where appropriate. **When delegation is justified and not a smell:** an Adapter or anti-corruption layer translating between models; a Proxy adding lazy loading, caching, retries, authorization, or instrumentation; a Facade deliberately narrowing a subsystem; a stable published interface insulating clients from a volatile implementation. "Delegating and adding nothing *yet*" for a boundary you intend to keep is a design decision, not automatically a smell. ## The dial Message Chains and Middle Man sit at opposite ends of one continuum: ``` client navigates everything client is told everything (Message Chains) <--------------------> (Middle Man) Hide Delegate --> <-- Remove Middle Man ``` Fowler's guidance is explicitly that you decide *per relationship*, and that reasonable designers land in different places. The productive question is: **which type do you want the client coupled to, and which types do you want free to change?** Hide the hops through volatile internals; expose stable, meaningful collaborators directly. ## Practical judgement - Prefer moving the *behaviour* to the data over hiding the *navigation* — it removes the chain instead of wrapping it. - Do not count dots; ask whether the intermediate types are ones you are willing to be coupled to. - A chain repeated in many clients is far more urgent than a single occurrence. - Chains over immutable value objects and configuration records are usually fine.