Introduction

Sometimes code starts to look like a train: order.getCustomer().getAddress().getCity().getName().
It technically works, but it exposes a lot of internal structure and makes your code tightly coupled to many classes at once.

The Law of Demeter (LoD) exists to prevent that.
It encourages you to design objects that only talk to their immediate friends, not to distant strangers they reach through a chain of calls.

This article explains the Law of Demeter in beginner‑friendly language, shows “bad” and “better” examples, and gives you practical rules you can apply in your Low-Level Designs.

What Is the Law of Demeter?

The Law of Demeter is also known as the Principle of Least Knowledge.

A common informal definition is:

A method of an object should only call methods of:

  • itself

  • its own fields (member objects)

  • objects passed in as parameters

  • objects it creates locally inside the method

In simpler words:

  • A class should only interact with objects it directly knows.

  • It should not dig through one object to reach another and then call methods on that deeper object.

So “talk to your friends, not your friends’ friends.”

Why the Law of Demeter Matters

When you violate LoD with long call chains:

  • High coupling

    • Your method now depends on many classes’ internal structures at once.

    • Changing any of those classes can break your code.

  • Leaky encapsulation

    • You expose internal details of one object so others can poke into them.

    • It becomes harder to change the internal model later.

  • Harder to test and maintain

    • You need more setup in tests (many related objects).

    • Reading the code requires understanding several classes at the same time.

When you follow LoD:

  • Each class has a small, clear set of collaborators.

  • Code is easier to change because changes stay local.

  • Methods become more intention‑revealing: they ask for what they want instead of navigating object graphs.

Classic “Train Wreck” Example (Violating LoD)

Consider a simple domain:

  • Order has a Customer.

  • Customer has an Address.

  • Address has a City.

You might see code like this:


This is sometimes called a train wreck: a long chain of dots.

Problems:

  • getOrderCityName now depends on the internal structure of Order, Customer, and Address.

  • If you change how Order stores Customer, or how Customer stores AddressHis function breaks.

  • The function is “talking,” not just to its friends but to friends of friends of friends.

Applying LoD: Ask Objects to Do Things for You

Instead of reaching through many layers, ask the object you already have to give you what you need, or to perform the action itself.

Step 1: Add an Intention‑Revealing Method on Order


Step 2: Let the Customer Hide Its Own Structure


Step 3: Address Knows How to Get City Name


Now the caller can write:


Changes:

  • The caller only “talks” toOrder, its direct friend.

  • Order talks to Customer, Customer talks toAddress, etc.

  • Each level hides its internal details and exposes simple methods.

If tomorrow you change how Customer  CustomerThe code needs to change; not every caller needs the city name.

Another Example: Payment and User Account

Bad pattern:


This method:

  • Reaches into Order → User → Account and manipulates account details directly.

  • Knows too much about how a refund is applied to an account.

LoD‑friendly refactor:

Add behavior to the objects that should own it.


Now the high‑level code becomes:


The refund logic is now:

  • Encapsulated where it belongs (User/Account).

  • Hidden behind simple, intention‑revealing methods.

  • Compliant with LoD because each method only talks to its direct collaborators.

Practical Rules of Thumb for LoD

When writing methods, try to limit calls to:

  • this (current object)

  • Fields/members of this

  • Parameters passed to the method

  • Objects created inside the method

Avoid:

  • Long chains like a.getB().getC().doSomething()

  • Reaching into objects just to reach further into their internals

  • Exposing internal getters everywhere that encourage deep traversal

Instead:

  1. Add methods that express intent

    • Example: order.getCityName() instead of navigating through getCustomer().getAddress().getCity().getName().

  2. Let each class manage its own data

    • Put behavior near the data it uses.

    • If a class knows about its own structure, it can provide simple methods for others.

  3. Reduce getter exposure when possible

    • Too many getters can invite LoD violations.

    • Expose higher‑level operations instead of raw internal objects when appropriate.

How LoD Fits with Other Principles

  • SRP (Single Responsibility)

    • Putting behavior close to the data that owns it supports SRP and helps respect LoD.

  • DIP (Dependency Inversion)

    • Depending on abstractions with clear, small interfaces makes it easier to avoid poking into deep object graphs.

  • KISS and YAGNI

    • LoD helps keep the interactions simple and local, which aligns with keeping designs straightforward and not over‑complicated.

All of these work together to make yourLow-Levell Designs easier to reason about and safer to change.

Summary

The Law of Demeter (Principle of Least Knowledge) says that an object should only talk to its immediate friends, not to friends of friends reached through long call chains.

You learned:

  • The core rule: a method should call methods only on itself, its fields, its parameters, or locally created objects.

  • Why do long method chains  a.getB().getC().doSomething() create tight coupling and break encapsulation?

  • How to refactor such code by moving behavior into the right classes and exposing intention‑revealing methods (like order.getCityName()  order.refundUser()).

  • Practical rules of thumb for keeping your code compliant with LoD and how it fits with SRP, DIP, KISS, and YAGNI.