Why Law of Demeter in LLD? - Purpose & Use Cases

The Big Idea

What if your software could protect itself from breaking every time you change one small part?

The Scenario

Imagine you are building a complex software system where many parts need to talk to each other. Without clear rules, each part might reach deep inside other parts to get what it needs, like asking a friend to get a book from their friend's shelf instead of asking the friend directly.

The Problem

This deep reaching makes the system fragile and hard to fix. If one part changes inside, many others break because they depended on those inner details. It's like if your friend moves the book to a new shelf, you have to find out and change your way of asking everywhere.

The Solution

The Law of Demeter tells us to only talk to our immediate friends, not their friends. This keeps each part simple and independent. If something inside changes, only the direct friend needs to know, not everyone.

Before vs After

✗ Before

order.getCustomer().getAddress().getZipCode()

✓ After

order.getCustomerZipCode()

What It Enables

It enables building software that is easier to maintain, less error-prone, and more flexible to change.

Real Life Example

Think of a restaurant where the waiter asks the chef directly for the dish instead of asking the chef's assistant to ask the chef. This speeds up service and avoids confusion.

Key Takeaways

Reduces dependencies between parts of a system.

Makes code easier to change and fix.

Encourages clear and simple communication paths.