Law of Demeter (Principle of Least Knowledge)

The rule, precisely

A method m of an object O may only call methods on a short list of friends. Anything else is reaching through a stranger.

• `O` itself — its own other methods (this.helper()).
• `O`'s own fields — objects it holds directly (this.sender.send(...)).
• The method's parameters — objects handed in to m (order.total()).
• Objects `m` creates — anything m news up itself (new Logger().log(...)).

What's not on the list is the giveaway: objects returned by another method call. The moment you call a method and then call a method on its result, you're talking to a stranger you were introduced to by a friend. One dot is fine. It's the second dot on a returned object that starts the trouble.

The classic smell: a train wreck

When several of these reaches chain together, you get what people call a train wreck — a long line of dots, each car coupled to the next:

// ⚠️ a "train wreck" — every dot reaches deeper into a stranger
const number = order.getCustomer().getWallet().getCard().getNumber();

Count what this one line now knows. It knows an Order has a Customer, that a Customer has a Wallet, that a Wallet has a Card, and that a Card has a number. That's four classes welded into a single statement. The day a Wallet stops holding a single Card — say it becomes a list — this line breaks, even though it was only ever trying to charge a card. You reached through three strangers to do it.

The fix: ask your friend to do the work

Don't reach for the data — tell your friend to do the job. Add a method to the object right in front of you (Order) that does the work, so it deals with its own collaborators:

// ✓ talk to your friend Order; let Order handle its own Wallet & Card
order.chargeCard(amount);

class Order {
  // Order is allowed to talk to its OWN fields — they're its friends.
  chargeCard(amount: number) {
    this.customer.charge(amount);   // pass the job one step down
  }
}

Now your code knows about exactly one class: Order. It has no idea whether a Customer has a Wallet, a Wallet has a Card, or how charging actually happens. Each object handles the layer directly below it and hides the rest. If the wallet-to-card relationship changes tomorrow, only Customer has to know — your code never finds out.

Where it does NOT apply: this isn't a 'count the dots' law

Demeter is about who you talk to, not about how many dots you type. Some chains are perfectly fine:

• Fluent builders / chaining — new StringBuilder().append("a").append("b").toString() returns this each time, so every call is still the same friend. No strangers are involved.
• Streams / pipelines — list.stream().filter(...).map(...).collect(...) chains operations on one pipeline object, not a walk through unrelated classes.
• Data Transfer Objects — a plain bag of public data with no behaviour (a config tree, a parsed JSON object) isn't a 'stranger' hiding logic; reading nested fields off it is reading data, not violating Demeter.

Reach for it when a chain digs through other objects' guts

The Law of Demeter is most useful exactly where a long getter chain is forming. If you catch yourself writing a third dot on a returned object, stop and ask whether the first object could do the whole job for you.

• Train-wreck getter chains — a.getB().getC().getD(). Push the behaviour onto a so it hides the chain.
• Code that breaks far from where you edited — if renaming a field in Wallet breaks a checkout screen, a train wreck is reaching through it. Demeter localises that ripple.
• Rich domain objects — when objects have real behaviour (not just data), 'tell, don't ask' keeps logic next to the data it uses.
• Wrapping awkward third-party trees — give yourself one friendly method instead of walking a library's nested structure everywhere.