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.