The Law of Demeter

The Law of Demeter is a precise rule, not “avoid dots”. A method m on object O may only call methods on a small, named set of objects: O itself (its own fields and methods), the parameters passed into m, any objects m creates, and O’s direct component objects. It may not call methods on objects returned by those calls. In one sentence: talk to your friends, not to strangers your friends introduce you to.

class ReportService {
  constructor(private readonly db: Database) {}

  build(request: ReportRequest): Report {
    this.normalise(request);        // OK — own method
    request.validate();             // OK — a parameter
    const rows = this.db.query();   // OK — own field
    const out = new ReportBuffer(); // OK — created here
    return out.finish();            // OK — object we made

    // NOT OK: this.db.getConnection().getPool().getStats()
    // — getConnection() returns a stranger; we never met the pool.
  }
}

The rule is about return values. The moment you call a method on something another method handed back, you’ve stepped past your friends and started depending on a stranger’s internals.

A train-wreck chain couples the caller to the entire path’s shape, not just its endpoint. Consider order.getCustomer().getAddress().getCountry().getCode(). This line cares about one thing — a country code — but it has structurally bound itself to four facts: that Order exposes a Customer, that Customer exposes an Address, that Address exposes a Country, and that Country exposes a getCode(). Change any link and the caller breaks.

// The caller "knows" the whole graph just to read one leaf:
const code = order.getCustomer().getAddress().getCountry().getCode();

Now multiply by every place that does the walk. The blast radius of “rename Country.getCode() to getIsoCode()” is no longer Country — it is every call site that ever traversed through a country to reach the code. The chain turned a local change into a global one. This is why structural coupling, not behavioural coupling, is the expensive kind: behaviour you can mock, but shape you have hard-wired into the caller.

The fix is “tell, don’t ask”: move the behaviour to where the data lives. Instead of asking an object for its parts so you can compute something, tell the object what you want and let it compute it with parts it already owns. The chain collapses because each object only ever reaches one hop.

class Country  { constructor(private code: string) {} isoCode() { return this.code; } }
class Address  { constructor(private country: Country) {} countryCode() { return this.country.isoCode(); } }
class Customer { constructor(private address: Address) {} countryCode() { return this.address.countryCode(); } }
class Order    { constructor(private customer: Customer) {} countryCode() { return this.customer.countryCode(); } }

// Caller now talks only to its friend:
const code = order.countryCode();

The caller depends on exactly one thing: that Order can tell it a country code. How Order gets there — through customer, address, country — is now Order’s private business. Rename Country.getCode, restructure Address, swap the whole chain for a cache: the caller never notices. You have traded a wide, brittle dependency for a narrow, stable one.

The failure mode: dogmatic LoD breeds the Middle Man smell. Look again at Address.countryCode() and Customer.countryCode() — they do nothing but forward the call one level down. Apply the law mechanically across a large graph and you generate a forest of these pass-through methods: every layer grows a delegating method for every leaf any caller might want. Now a new field on Country means adding the same trivial forwarder to Address, Customer, and Order. You’ve replaced one localised change-amplification (the chain) with another (the wrapper cascade). When a class delegates almost everything and adds nothing, that is the Middle Man code smell, and the cure is the opposite refactor — Remove Middle Man: let the caller talk to the delegate directly.

// Middle Man: Order forwards everything to Customer and contributes no logic.
class Order {
  constructor(private customer: Customer) {}
  name()        { return this.customer.name(); }
  email()       { return this.customer.email(); }
  countryCode() { return this.customer.countryCode(); }
  tier()        { return this.customer.tier(); }   // ...and on, and on
}

So the Law of Demeter is a heuristic about coupling, not a syntactic ban on chained calls. The senior question is never “are there two dots?” but “does this chain make me depend on structure I have no business knowing — and does hiding it add real behaviour, or just a forwarder?”