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.

Practice

1.

What is the main idea behind the Law of Demeter in system design?

easy

A. An object should only communicate with its immediate friends.

B. An object can access any part of the system freely.

C. Objects should share all their internal details with others.

D. Objects must avoid any communication with other objects.

Solution

1. Step 1: Understand the Law of Demeter principle

   The Law of Demeter states that an object should only talk to its immediate friends, meaning it should not reach deep into other objects.

2. Step 2: Match the principle to the options

   An object should only communicate with its immediate friends. correctly describes this idea, while others contradict it.

3. Final Answer:

   An object should only communicate with its immediate friends. -> Option A

4. Quick Check:

   Law of Demeter = Talk only to immediate friends [OK]

Hint: Remember: Only talk to your immediate friends [OK]

Common Mistakes:

• Thinking objects can access any part of the system
• Believing objects should share all internal details
• Assuming no communication is allowed between objects

2.

Which of the following code snippets follows the Law of Demeter?

class Car {
  Engine engine;
  void start() {
    engine.start();
  }
}

easy

A. Calling engine.start() directly inside Car is allowed.

B. Accessing engine.fuel.tank.level inside Car is allowed.

C. Calling engine.getFuel().getTank().getLevel() is preferred.

D. Car should access engine.fuel.tank.level directly.

Solution

1. Step 1: Identify allowed communication

   According to the Law of Demeter, Car can call methods on its direct member engine.

2. Step 2: Analyze the options

   Calling engine.start() directly inside Car is allowed. shows Car calling engine.start(), which is allowed. Options A, B, and C involve accessing deeper nested objects, which breaks the law.

3. Final Answer:

   Calling engine.start() directly inside Car is allowed. -> Option A

4. Quick Check:

   Direct member calls = Allowed [OK]

Hint: Only call methods on your direct members [OK]

Common Mistakes:

• Accessing nested objects directly
• Chaining multiple getters in one call
• Ignoring encapsulation principles

3.

Consider this code snippet:

class A {
  B b;
  void doSomething() {
    int x = b.getC().getValue();
    System.out.println(x);
  }
}

Which statement about this code is true regarding the Law of Demeter?

medium

A. It follows the Law of Demeter perfectly.

B. It violates the Law of Demeter by chaining calls.

C. It violates the Law of Demeter by not calling b directly.

D. It follows the Law of Demeter by accessing getValue().

Solution

1. Step 1: Analyze the method call chain

   The code calls b.getC().getValue(), which chains two calls to reach a nested object.

2. Step 2: Compare with Law of Demeter

   The Law of Demeter discourages chaining calls like this; an object should only call methods on its direct members.

3. Final Answer:

   It violates the Law of Demeter by chaining calls. -> Option B

4. Quick Check:

   Chained calls = Violation [OK]

Hint: Watch out for chained method calls [OK]

Common Mistakes:

• Thinking chained calls are allowed
• Confusing direct member calls with nested calls
• Ignoring encapsulation rules

4.

Identify the problem in this code snippet related to the Law of Demeter and suggest a fix:

class Order {
  Customer customer;
  void printCustomerCity() {
    System.out.println(customer.getAddress().getCity());
  }
}

medium

A. No problem; code follows the Law of Demeter.

B. Violation: Order should print city without any method calls.

C. Violation: Order should access Address directly. Fix by removing Customer.

D. Violation: Order accesses nested Address. Fix by adding getCity() in Customer.

Solution

1. Step 1: Identify Law of Demeter violation

   Order calls customer.getAddress().getCity(), chaining calls to nested objects.

2. Step 2: Suggest fix to follow Law of Demeter

   Add a getCity() method in Customer that returns the city, so Order calls only customer.getCity().

3. Final Answer:

   Violation: Order accesses nested Address. Fix by adding getCity() in Customer. -> Option D

4. Quick Check:

   Use direct member methods to avoid chaining [OK]

Hint: Add helper methods to avoid deep calls [OK]

Common Mistakes:

• Ignoring nested call chains
• Removing needed objects instead of fixing access
• Trying to print without method calls

5.

You are designing a messaging system where ChatRoom has User objects, and each User has a Profile. To follow the Law of Demeter, how should ChatRoom get a user's display name?

hard

A. Make Profile public and access displayName directly.

B. chatRoom.getUser().getProfile().getDisplayName() chaining calls is fine.

C. Add a method getDisplayName() in User and call chatRoom.getUser().getDisplayName().

D. Let ChatRoom access Profile objects directly.

Solution

1. Step 1: Identify Law of Demeter violation in chaining

   Chaining calls like getUser().getProfile().getDisplayName() breaks the Law of Demeter.

2. Step 2: Apply Law of Demeter by adding helper method

   Adding getDisplayName() in User lets ChatRoom call only one method on its direct friend User.

3. Final Answer:

   Add a method getDisplayName() in User and call chatRoom.getUser().getDisplayName(). -> Option C

4. Quick Check:

   Use helper methods to avoid deep chains [OK]

Hint: Use helper methods in immediate objects [OK]

Common Mistakes:

• Allowing chained calls
• Making internal objects public
• Accessing nested objects directly