Law of Demeter in LLD - System Design Guide

Problem Statement

When objects reach deeply into other objects to access data or methods, the code becomes tightly coupled and fragile. Changes in one part ripple through many others, making maintenance and testing difficult.

Solution

This pattern limits object interactions to only immediate friends, avoiding chains of calls. Each object only talks to its direct collaborators, reducing dependencies and making the system easier to change and understand.

Architecture

┌─────────┐       ┌─────────┐       ┌─────────┐
│ Client  │──────▶│ ObjectA │──────▶│ ObjectB │
└─────────┘       └─────────┘       └─────────┘

Without Law of Demeter: Client calls ObjectA, then ObjectB through ObjectA (chain).

With Law of Demeter: Client calls only ObjectA, which internally calls ObjectB.

The diagram shows how a client should only communicate with its direct object (ObjectA), not with ObjectB inside ObjectA, following the Law of Demeter.

Trade-offs

✓ Pros

→

Reduces coupling between classes, making code easier to maintain.

→

Improves encapsulation by hiding internal object structures.

→

Simplifies testing by limiting dependencies.

✗ Cons

→

May increase the number of wrapper methods, adding boilerplate code.

→

Can lead to more classes or interfaces to maintain.

→

Sometimes reduces performance due to additional method calls.

Use when your system has complex object graphs and you want to reduce tight coupling and improve maintainability.

Avoid when performance is critical and the overhead of extra method calls is unacceptable, or in very simple systems where added abstraction is unnecessary.

Real World Examples

Amazon

Amazon applies Law of Demeter in their microservices to avoid tight coupling between services, enabling independent deployment and easier maintenance.

Netflix

Netflix uses this principle in their backend code to keep service interactions simple and reduce cascading failures.

LinkedIn

LinkedIn applies Law of Demeter in their API design to ensure clients only interact with direct APIs, hiding internal service details.

Code Example

Before: The Driver accesses the Engine through Car, creating tight coupling and exposing internal details. After: The Driver only calls Car's start_engine method, hiding Engine details and following Law of Demeter.

LLD

### Before applying Law of Demeter (violating) ###
class Engine:
    def start(self):
        print('Engine started')

class Car:
    def __init__(self):
        self.engine = Engine()

class Driver:
    def __init__(self):
        self.car = Car()

    def drive(self):
        # Driver reaches into car to start engine directly
        self.car.engine.start()


### After applying Law of Demeter (applying) ###
class Engine:
    def start(self):
        print('Engine started')

class Car:
    def __init__(self):
        self.engine = Engine()

    def start_engine(self):
        self.engine.start()

class Driver:
    def __init__(self):
        self.car = Car()

    def drive(self):
        # Driver only talks to car, not engine directly
        self.car.start_engine()

Alternatives

Facade Pattern

Facade provides a simplified interface to a complex subsystem, while Law of Demeter restricts object interactions to immediate friends.

Use when: Choose Facade when you want to provide a single entry point to a complex system.

Mediator Pattern

Mediator centralizes communication between objects, whereas Law of Demeter limits direct communication to immediate objects.

Use when: Choose Mediator when you want to reduce many-to-many communication to one-to-many.

Summary

Law of Demeter prevents objects from reaching deeply into others, reducing tight coupling.

It improves maintainability by limiting interactions to immediate collaborators only.

This leads to clearer, more robust code but may add some boilerplate.