Law of Demeter

A method talks only to its own object, its parameters, the objects it creates and its own fields. It never reaches through one object to work on the insides of another.

Overview

The Law of Demeter is a rule about who a method may talk to. It was found at Northeastern University in 1987 by Ian Holland, while the team built the Demeter system, and published by Lieberherr, Holland and Riel at OOPSLA in 1988. The short form is: only talk to your immediate friends. The point is coupling. Every object your code reaches into is an object whose structure your code now depends on.

What the rule says

Inside a method, you may call methods on a short list of things. Anything else is a stranger, and you should not send it messages.

The object itself — self.apply_discount()
The method's parameters — coupon.rate() when coupon was passed in
Objects the method creates — Money(0).add(...)
The object's own fields — self.lines
Objects returned by the object's own methods — self.customer() (class form of the rule)

The 1988 paper gives two forms. The object form says what we really want: talk only to objects you hold directly. It cannot be checked by a compiler. The class form, which tools such as PMD implement, checks the types instead, and is what most people mean by the rule.

The train wreck

The clearest violation is a chain of calls that walks across several objects. David Bock's paperboy example puts it well. A paperboy collects two dollars. In the bad version he asks the customer for the wallet, checks the amount and takes the money himself.

The fix is to tell the customer what you want. The customer decides how to pay. The paperboy never learns that a wallet exists.

In code the smell looks like customer.get_wallet().subtract(amount) or order.customer.address.city. Each dot after the first is a class your code did not need to know about.

Tell, don't ask

The Law of Demeter and the tell-don't-ask idea are two sides of one habit. Tell-don't-ask, usually credited to Andy Hunt and Dave Thomas, says: do not pull data out of an object and make the decision outside it. Tell the object what you want and let it decide, because it has the data.

Martin Fowler notes a limit worth repeating in an interview: this is not a ban on getters. Objects still answer questions. The problem is a caller that walks a chain of objects to make a decision that one of those objects should own.

What it costs

The 1988 paper is honest about the price. Following the rule removes nested calls and makes each method simpler, but it adds methods and sometimes arguments. Each pass-through method (customer.pay() that calls wallet.subtract()) is one more thing to name, test and read.

Fewer classes each method depends on — More small methods on the owning classes
Structure hiding: callers cannot see how objects nest — Sometimes an extra parameter to avoid a chain
Changes to inner classes stop at their owner — Interfaces of owning classes get wider

The trade is usually worth it on domain objects, where structure changes often. It is not worth it on plain data carriers or on APIs built for chaining.

What is not a violation

A chain of dots is not always a chain of strangers. Ask one question: does each call return a different object whose structure I am now walking into, or the same object, or a new value in the same pipeline?

sb.append("a").append("b") — fine — Java's StringBuilder.append returns a reference to the same object
items.stream().filter(f).map(g).toList() — fine — each step returns a new pipeline value, not another object's insides
order.customer().address().city() — violation — three business objects, three structures your code now knows
config.database.host on a plain record — usually fine — a data record with no behavior; there is nothing to encapsulate

PMD's LawOfDemeter rule follows the same logic: this is fully trusted, parameters and new objects are one step away, and builder-style calls are allowed.

What you will be able to do

Spot a train wreck in a code sample and say which classes it couples.
Refactor it by moving the decision to the object that owns the data.
Explain the difference between a builder chain and a navigation chain.
State the trade-off (fewer dependencies, more methods) instead of calling the rule absolute.

Interview questions

How do you identify Law of Demeter violations?
How do you fix violations without creating a pile of wrapper methods?
When is a chain of calls acceptable?
How does the Law of Demeter relate to encapsulation and coupling?
Does the rule apply between services, not just objects?