Message chains & middle man

A message chain couples the caller to the entire path, not just the endpoint. When code reads a.getB().getC().getD(), the caller has hard-coded the shape of the graph: that A exposes a B, that B exposes a C, that C exposes a D. Every intermediate type is now part of the caller’s compile-time contract, even though the caller only wanted the final value.

// The caller "knows" Order → Customer → Address → string
const city = order.getCustomer().getAddress().getCity();

The blast radius is the length of the chain. Change any link — rename getAddress, make Customer.address nullable, move city up to Customer — and every call site that walked through it breaks. The caller paid for knowledge it never needed: it wanted a city, but it bought a map of three objects’ internals.

Hide delegate: ask the nearest object for what you want, and let it walk the rest of the chain. The cure for a message chain is usually hide delegate — push the navigation behind the object you already hold, so the caller depends only on its immediate neighbour.

class Order {
  constructor(private customer: Customer) {}
  // the caller's "one friend" exposes the endpoint directly
  get shippingCity(): string {
    return this.customer.address.city; // Order owns this walk; the caller doesn't
  }
}

// caller now touches one type, not three
const city = order.shippingCity;

This is the Law of Demeter (“only talk to your immediate friends”) applied as a refactoring: the caller talks only to Order. If Address later folds into Customer, the only place that breaks is inside Order.shippingCity — one edit, not forty. The chain didn’t disappear; it moved to the object that legitimately owns the relationship.

Middle man is hide-delegate taken too far: a class whose methods only forward. Apply hide delegate to everything and you get the opposite smell. If half of Order’s methods are one-line forwards to customer, Order has become a middle man — a pass-through tax. Every new method on Customer now needs a twin delegating method on Order, and every reader has to hop through the forward to find out where the work actually happens.

class Order {
  constructor(private customer: Customer) {}
  // none of this does anything but forward — pure pass-through
  get name() { return this.customer.name; }
  get email() { return this.customer.email; }
  get city() { return this.customer.address.city; }
  get phone() { return this.customer.phone; }
}

The cure is remove middle man: delete the forwarding methods and let callers talk to the real object — order.customer.email. Trading a chain for an empty wrapper isn’t progress; you’ve added a class to maintain that carries no behaviour of its own.

Tell-don’t-ask often dissolves both smells at once. Chains and middle men frequently appear because the caller asks for data and then acts on it elsewhere — pulling the city out to compute shipping somewhere far from the data. Move the behaviour to the data instead: tell the object to do the work.

// ASK: caller reaches in, gets data, decides — chain + logic far from data
const city = order.getCustomer().getAddress().getCity();
const fee = isRemote(city) ? 15 : 5;

// TELL: the object that owns the data answers the real question
class Order {
  shippingFee(): number {
    return this.customer.isRemote() ? 15 : 5; // graph stays private
  }
}
const fee = order.shippingFee();

Now no caller walks the graph and no wrapper exists purely to forward getCity. The senior move is to ask why the caller wanted that deep value at all — often the honest answer is a method that should have lived on the object, not a navigation that needs hiding.

The judgment: balance, not zealotry — Demeter taken to the limit manufactures middle men. Here is the tension the two smells expose. The Law of Demeter says “don’t reach through objects,” which pushes you toward hide delegate. But mechanically obeying it for every access means wrapping every neighbour’s neighbour in a forwarding method — which is exactly how you create middle men. The two smells pull against each other: zero delegation gives you brittle chains; total delegation gives you pass-through towers.

So the rule is not “eliminate all chains” or “eliminate all delegation.” Some delegation is healthy encapsulation — it hides a relationship the caller has no business knowing. Too much is noise — wrappers that hide nothing because the relationship is part of the public model anyway (a list.length, a Promise.then, a fluent builder are chains you should leave alone). The skill is reading which is which: does this delegation hide something likely to change, or does it just relay something already public?