Law of Demeter — The Principle of Least Knowledge in Java OOP

The Law of Demeter, or principle of least knowledge, says a method should only talk to its immediate friends — itself, its parameters, the objects it creates, and its direct fields. Don't talk to strangers. The violation is the train wreck: order.getCustomer().getAccount().getBalance() — the caller reaches through three objects to get what it needs.

The reason this matters is coupling math. Each dot in that chain is a dependency on one class's shape. The caller now depends on Order, Customer, and Account — three classes whose API changes can break it, even though the caller never owned a Customer or an Account. The fix is to push the knowledge down: instead of the caller navigating the graph, Order exposes getCustomerBalance(), and the caller only talks to Order. Coupling drops from three classes to one, and Customer and Account can change freely.

This is the same coupling-reduction idea as depending on interfaces, but at the method-call level. It's also called 'tell, don't ask' — instead of asking an object for its data and acting on it, tell the object to do the thing itself.

The nuance is that LoD is a heuristic, not a rule. Fluent APIs like Stream and StringBuilder chain on purpose — each call returns the same type, so there are no strangers. DTOs and records are pure data — a chain on a parsed JSON object is the data's shape, not a coupling hazard. Blindly pushing every getB().getC() down creates a wrapper-explosion god class that forwards everything. The principle is sound — minimize the classes a caller depends on — but you apply the intent, not the dot count.