Law of Demeter in LLD - System Design Exercise

Design: Law of Demeter Application in Software Design

Focus on the design principles and object interactions within a single module or small system. Out of scope are distributed systems, network communication, or database design.

Functional Requirements

FR1: Design a software module that follows the Law of Demeter to reduce coupling.

FR2: Ensure that objects only communicate with their immediate friends.

FR3: Avoid chaining calls that reach deep into object structures.

FR4: Demonstrate how to refactor a tightly coupled design into a loosely coupled one.

Non-Functional Requirements

NFR1: The design should minimize dependencies between modules.

NFR2: The system should be easy to maintain and extend.

NFR3: Latency and performance should not degrade significantly due to added abstraction.

NFR4: The design should be understandable by developers new to the project.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

Key Components

Objects and their immediate collaborators

Interfaces or methods that expose internal structure

Encapsulation boundaries

Refactoring techniques to reduce coupling

Design Patterns

Facade pattern to hide complex subsystems

Mediator pattern to centralize communication

Tell, Don't Ask principle

Encapsulation and information hiding

Reference Architecture

Client
  |
  v
Module A (Facade)
  |
  v
Module B (Internal Objects)

- Client calls only Module A
- Module A communicates with Module B
- No direct calls from Client to Module B
- No chained calls like client.getA().getB().doSomething()

Components

Client

Any OO language

Uses the module through a simple interface without knowing internal details

Module A (Facade)

Any OO language

Provides a simplified interface and hides internal object structure

Module B (Internal Objects)

Any OO language

Contains detailed logic and data, accessed only by Module A

Request Flow

1. Client calls a method on Module A.

2. Module A performs necessary operations by calling its internal objects (Module B).

3. Module B executes logic and returns results to Module A.

4. Module A returns the final result to Client.

5. Client never calls methods on Module B directly or chains calls.

Database Schema

Not applicable as this design focuses on object interactions and coupling.

Scaling Discussion

Bottlenecks

Excessive method calls in facade can become complex.

Facade might become a god object if not carefully designed.

Performance overhead due to additional abstraction layers.

Difficulty in identifying direct collaborators if facade is too generic.

Solutions

Split facade into smaller facades for different responsibilities.

Use mediator pattern to manage complex interactions.

Profile and optimize critical paths to reduce overhead.

Maintain clear documentation of object relationships and interfaces.

Interview Tips

Time: Spend 10 minutes explaining the Law of Demeter and its importance, 15 minutes designing a simple example with a facade, and 10 minutes discussing scaling and trade-offs.

Explain how Law of Demeter reduces coupling and improves maintainability.

Show how to identify violations by spotting chained calls.

Demonstrate refactoring using facade or mediator patterns.

Discuss trade-offs between abstraction and performance.

Highlight benefits for team collaboration and code readability.