---
title: Law of Demeter
description: A method should only talk to its immediate friends, not to strangers.
tokens: ~460
---

# Law of Demeter

Also called the principle of least knowledge. A method should only talk to its immediate friends, not reach through objects to access distant parts of the system.

If you see code like `order.getCustomer().getAddress().getZipCode()`, that's violating the Law of Demeter.

## Example

`Driver` reaching through `Car` to start the engine directly:

```typescript
class Driver {
  drive(car: Car): void {
    car.getEngine().start(); // knows too much about Car's internals
  }
}
```

`Car` should expose behaviour, not its guts:

```typescript
class Car {
  private engine = new Engine();

  startEngine(): void {
    this.engine.start(); // Car handles its own internals
  }
}

class Driver {
  drive(car: Car): void {
    car.startEngine(); // only talks to its immediate friend
  }
}
```

Now `Driver` is coupled to `Car`, not to `Car`'s `Engine`. If the engine implementation changes, `Driver` doesn't care.

## The chaining distinction

Builder chains are not a violation:

```typescript
builder.setName("Alice").setAge(30).build();
```

Each call returns the same object type, so we're not traversing into stranger territory.

The problem is specifically when chaining leaks internal structure by jumping through multiple different object types — `a.getB().getC().doSomething()` is the red flag.

## In Practice

- **Expose behaviour, not data** — keep fields private and give callers methods that do the work
- **Add higher-level methods** — if callers repeatedly dig through your object to reach something, put a method on your object that returns exactly what they need
- **Use a Facade** — when interacting with a complex subsystem, wrap it in a higher-level interface so callers never need to reach inside
- **Pass what you need** — prefer injecting the specific object a method needs over passing a container it has to dig through