The Law of Demeter (LoD) states that each object should only communicate with its immediate neighbors—and no one else. Also known as the Principle of Least Knowledge, this software design guideline encourages loose coupling between components.

The law originated in 1987 at Northeastern University during the Demeter Project, a research initiative focused on adaptive programming. The name comes from Demeter, the Greek goddess of agriculture—fitting, since the principle helps cultivate well-structured code.

The Formal Rules

A method of an object may only invoke methods on:

1. The object itself (this)
2. Objects passed as arguments to the method
3. Objects instantiated within the method
4. The object’s direct component objects (its fields)

Explicitly prohibited: calling methods on objects returned by other method calls. When you reach through one object to access another, you’re talking to a stranger.

Why Strangers Are Dangerous

When Class A calls methods on an object obtained from Class B, Class A now has implicit knowledge of Class B’s internal structure. This creates hidden dependencies. If Class B’s implementation changes—perhaps it returns a different type, or restructures how it manages that relationship—Class A breaks despite having no direct relationship with the changed code.

Examples

Example 1: Violation

public class A {
    private B b = new B();
    
    public void doWork() {
        C c = b.getSomething();
        c.doSomethingElse();
    }
}

Class A depends on both B and C. Changes to C’s interface require modifications to A, even though A should only care about B.

Example 2: Train Wreck Violation

public class A {
    private B b = new B();
    
    public void doWork() {
        b.getSomething().doSomethingElse();
    }
}

This chained form—often called a “train wreck”—has the same coupling problem as Example 1, compressed into a single line. The terse syntax obscures the dependency and complicates debugging: when an exception occurs somewhere in the chain, identifying the failure point becomes unnecessarily difficult.

Example 3: Compliant

public class A {
    private B b = new B();
    
    public void doWork() {
        b.doSomething();
    }
}

public class B {
    public void doSomething() {
        C c = new C();
        c.doSomethingElse();
    }
}

Now only Class B depends on Class C. Changes to C affect only B; Class A remains untouched. The dependency graph stays shallow and explicit.

Scaling the Principle

While these examples are simple, imagine dozens of classes with similar violations throughout a codebase. The dependency graph becomes a tangled web where a single interface change cascades into modifications across unrelated modules. Code becomes brittle. Testing becomes difficult—mocking requires understanding transitive dependencies. The Law of Demeter prevents this entropy by keeping each class focused on its immediate collaborators.

Exceptions

Creational patterns represent legitimate exceptions:

Factory Pattern: Returns newly created objects to callers. Since the returned object is conceptually “created by the calling method” (the factory merely handles instantiation details), using it does not violate LoD.

Builder Pattern: Uses method chaining, but each method returns this—the same builder instance. This is a fluent interface, not a train wreck. No new object types are exposed; the caller interacts only with the builder throughout.

Data Transfer Objects / Value Objects: Simple data containers with getters (e.g., address.getCity()) are sometimes exempted, though purists argue even these should be avoided in favor of telling the containing object what to do.

---

Remember: Objects don’t talk to strangers.

© 2026 Chris Bollerud, Bollosoft. Unauthorized reproduction prohibited.