Skip to main content
Category: Principles
Type: Object-oriented design principle
Origin: Northeastern University, introduced around 1987 by Ian Holland and Demeter project collaborators
Also known as: Principle of Least Knowledge
Quick Answer — The Law of Demeter says a module should only talk to its close collaborators, not to distant internals through long call chains. It emerged from the Demeter project to reduce coupling and make code easier to change safely.

​
What is Law of Demeter?

The Law of Demeter is a design rule: each object should interact only with itself, its direct fields, its method parameters, and objects it creates directly.
Prefer “tell your direct collaborator what you need” over “navigate through many objects to get it yourself.”
In day-to-day code, this means avoiding “train wreck” calls such as a.getB().getC().doX(). It aligns with Single Responsibility Principle, Separation of Concerns, and Fail Fast to keep boundaries clear and failures local.

​
Law of Demeter in 3 Depths

  • Beginner: Avoid long dot chains; ask one object to do the job instead.
  • Practitioner: Add facade methods that hide deep structures and stabilize APIs.
  • Advanced: Treat LoD as boundary design that controls ripple effects in large systems.

​
Origin

The law was formulated in work around the Demeter Project at Northeastern University in the late 1980s, notably discussed in Ian Holland’s dissertation and related software engineering publications. Its practical motivation was maintainability: when code reaches through many layers, small structural changes in one class can break callers across the system. By constraining object interactions, teams reduce accidental dependency on internal structure. The idea later spread broadly through object-oriented practice and enterprise architecture guidelines as a core coupling-control technique.

​
Key Points

Law of Demeter works best as a communication boundary rule, not as a rigid syntax game.
1

Talk to friends, not strangers

A method should call methods on itself, direct collaborators, or newly created objects. Reaching into nested objects usually leaks structure.
2

Hide navigation behind intent methods

If a caller needs deep data, expose an intention-revealing method from the immediate collaborator rather than exposing internals.
3

Refactor train wrecks early

Long call chains are often an early signal of misplaced responsibilities and fragile boundaries.
4

Balance purity and readability

Strictly following LoD everywhere can create wrappers with little value. Keep the design goal: lower coupling with clear intent.

​
Applications

You can apply LoD in code review, API design, and team-level architecture standards.

Backend Service Layers

Replace chained repository-domain calls with service methods that expose business intent and hide object traversal.

Frontend State Management

Avoid deep component prop drilling by exposing selectors and view-model adapters at boundary points.

SDK and Library APIs

Design concise entry points so users do not depend on nested internal object graphs.

Team Code Review Checklists

Flag repeated train wreck calls as coupling hotspots and schedule targeted refactors.

​
Case Study

A common enterprise refactor pattern is replacing deep call chains in order-processing code with facade methods at aggregate boundaries. In one public engineering write-up pattern repeated across teams, reducing call-chain depth lowered the number of files touched per feature and cut regression incidents after model changes. A measurable indicator often used is change-surface size: teams track “files changed per ticket” and “post-release defect count.” After introducing boundary methods and removing deep navigation, these indicators typically improve because structural changes no longer propagate as widely.

​
Boundaries and Failure Modes

Law of Demeter is useful, but over-application creates new problems.
  • Wrapper explosion: Too many pass-through methods can obscure the domain model.
  • Anemic interfaces: Hiding everything may produce APIs that are hard to compose for legitimate advanced use.
  • False compliance: Code can satisfy LoD mechanically while still being tightly coupled at semantic level.

​
Common Misconceptions

Teams often reduce LoD to “never use dot chains,” which misses the real design intent.
Correction: Fluent APIs with stable semantics are different from leaking deep internal structures.
Correction: Extra layers help only when they express intent and protect boundaries from change.
Correction: The core idea applies in any architecture: keep interactions local to reduce change blast radius.
Law of Demeter is strongest when combined with adjacent boundary principles.

Single Responsibility Principle

Keeps each module focused so collaboration boundaries remain clear.

Separation of Concerns

Prevents cross-layer leakage that usually leads to long dependency chains.

Least Privilege

Applies a similar “minimum necessary access” mindset to security boundaries.

​
One-Line Takeaway

Law of Demeter reduces fragile coupling by keeping each module focused on direct collaborators instead of distant internals.