Law of Demeter Explained, With Examples

The Law of Demeter is a design rule for object-oriented code: an object should only talk to its immediate friends, not to strangers. In practice it means avoiding chains like a.getB().getC().doSomething(), where one class reaches through several others to get what it needs. It is also called the principle of least knowledge.

Where the name comes from

The rule was proposed by Ian Holland at Northeastern University in 1987, during the Demeter project led by Karl Lieberherr. Lieberherr and Holland published it as “Assuring Good Style for Object-Oriented Programs” in IEEE Software in September 1989. According to Wikipedia, the project was named after Demeter, the Greek goddess of agriculture. Northeastern still hosts the original formulation.

The formal rule

A method m of an object a may only call methods on:

• a itself
• the parameters of m
• objects created inside m
• the attributes (fields) of a
• global objects accessible to a in the scope of m

Everything else is a stranger. In languages that use a dot for member access, the rule is often summarised as “use only one dot”. That shortcut is useful but not exact, as we will see.

A Law of Demeter example

Here a checkout service charges a customer. It reaches into the customer, then into the wallet, then into the card:

class CheckoutService {
    public function charge(Customer $customer, Money $amount): void
    {
        $customer->getWallet()->getDefaultCard()->debit($amount);
    }
}

CheckoutService now knows that customers have wallets, that wallets have default cards and that cards can be debited. If the wallet changes, for example to support several payment methods, this class breaks too. That chain is often called a train wreck.

The fix is to ask the friend, and let the friend deal with its own friends:

class CheckoutService {
    public function charge(Customer $customer, Money $amount): void
    {
        $customer->pay($amount);
    }
}

class Customer {
    public function pay(Money $amount): void
    {
        $this->wallet->pay($amount);
    }
}

class Wallet {
    public function pay(Money $amount): void
    {
        $this->defaultCard->debit($amount);
    }
}

Each class now talks only to its direct collaborators. This is also known as “tell, don’t ask”: you tell the customer to pay instead of asking for its wallet.

When the “one dot” rule is wrong

The law is about knowledge, not punctuation. These chains do not break it:

• Fluent builders. query.where(...).orderBy(...).limit(10) returns the same object each time.
• Data structures. Reading order.shippingAddress.city from a plain data object is not reaching into behaviour.
• Streams. list.stream().filter(...).map(...) transforms values; it does not navigate an object graph.

Applied blindly, the rule can also fill classes with tiny wrapper methods that only forward calls. Use it where coupling hurts: across modules, between domain objects, and at boundaries that change often.

Why the shirt is funny

Our Demeter’s Law shirt is the most text-heavy design in the catalogue: the rule itself, printed as a cheat sheet. It is a subtle joke. Only people who know the law get it, and they will want to explain it to you. That is exactly the reviewer who leaves “too much coupling here” comments.

If your team prefers the other classic of clean code, pair it with Guard Clauses: return early instead of nesting ifs. More developer humour in our developer t-shirts, including the debugging classic It works, why?.

Unisex, S to 5XL, printed on demand. See the size guide.

How to spot violations in a code review

Look for code that navigates an object graph to reach behaviour. Common signs:

• Several getters in a row before a method that changes something.
• A test that needs mocks returning mocks returning mocks.
• A class that imports types it never creates or receives.
• A small change in one class forces edits in many unrelated ones.

Fixing a violation does not always mean adding wrapper methods. Sometimes the caller should receive the object it needs as a parameter, through dependency injection, instead of digging for it. If CheckoutService only needs a payment method, pass it the payment method. The class gets simpler, and its tests need fewer fakes.

The mocking sign is the most reliable. If the test for CheckoutService has to build a fake customer, a fake wallet and a fake card, the service knows too much. After the refactor, it needs one fake customer.

FAQ

Is the Law of Demeter the same as the principle of least knowledge?

Yes. Both names describe the same rule: a unit should know as little as possible about the structure of other units.

Who created the Law of Demeter?

Ian Holland proposed it at Northeastern University in 1987. He and Karl Lieberherr published it in IEEE Software in 1989.

Does the Law of Demeter apply to functional code?

Less directly. It targets objects that hide behaviour. Pipelines that transform data do not violate it.