Law of Demeter in LLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding the Law of Demeter Principle

Which of the following best describes the Law of Demeter in system design?

A A module should have direct access to all parts of the system to maximize flexibility.

B A module should avoid any communication with other modules to remain isolated.

C A module should always call methods on objects returned by other methods to chain operations.

D A module should only communicate with its immediate friends and not with strangers or friends of friends.

💡 Hint

Think about limiting the knowledge a module has about other parts of the system.

The Law of Demeter encourages modules to only talk to their immediate collaborators, reducing dependencies and improving maintainability.

❓ Architecture

intermediate

Identifying Law of Demeter Violation in Design

In the following design, which interaction violates the Law of Demeter?

Class A calls a method on Class B, which returns an object of Class C. Then Class A calls a method on Class C.

A Class A calling a method directly on Class B.

B Class B returning an object of Class C to Class A.

C Class A calling a method on the object of Class C returned by Class B.

D Class B calling a method on Class C internally.

💡 Hint

Consider which call crosses multiple object boundaries in one step.

Law of Demeter discourages calling methods on objects returned by other methods (friends of friends). Class A calling Class C's method violates this.

❓ scaling

advanced

Scaling a System While Respecting Law of Demeter

You are designing a large-scale e-commerce system. To keep the system maintainable, how should you apply the Law of Demeter when components need to access nested data?

A Let components chain multiple method calls on nested objects to get required data.

B Provide higher-level methods in each component to expose only necessary data, avoiding deep object navigation.

C Use global variables to share nested data across components for faster access.

D Allow components to access nested objects directly to reduce code complexity.

💡 Hint

Think about how to hide internal structure and reduce dependencies.

Providing higher-level methods encapsulates internal details and prevents components from reaching deep into nested objects, following the Law of Demeter.

❓ tradeoff

advanced

Tradeoffs When Strictly Applying Law of Demeter

What is a common tradeoff when strictly enforcing the Law of Demeter in a complex system?

A It can lead to excessive wrapper methods, increasing code verbosity and maintenance effort.

B It always improves performance by reducing method calls.

C It eliminates the need for interfaces and abstractions.

D It allows direct access to all nested objects, simplifying debugging.

💡 Hint

Consider what happens when you hide all internal details strictly.

Strict Law of Demeter can cause many small wrapper methods that forward calls, making code longer and sometimes harder to maintain.

❓ component

expert

Refactoring to Comply with Law of Demeter

Given the following code snippet, which refactoring best aligns with the Law of Demeter?

class Order {
  Customer customer;
  public String getCustomerCity() {
    return customer.getAddress().getCity();
  }
}

A Add a getCity() method in Customer that returns customer.getAddress().getCity(), then Order calls customer.getCity().

B Allow Order to access Address object directly and call getCity() as in the original code.

C Move getCity() method to Order class and have Order call customer.getCity() directly.

D Remove getCustomerCity() method and let external code call customer.getAddress().getCity() directly.

💡 Hint

Think about which class should hide the internal structure of its data.

Adding getCity() in Customer hides Address details from Order, reducing coupling and following the Law of Demeter.

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