Law of Demeter - Learning Module

Loading content...

0/246

Applying Demeter Appropriately

The Art of Principled Pragmatism

A senior engineer once told me: "The worst code I've ever seen was written by developers who learned design principles but not when to apply them."

The Law of Demeter, like all design principles, is a guideline — not a commandment carved in stone. Applied dogmatically, it can lead to absurd code: objects with hundreds of delegation methods, indirection layers that obscure meaning, and designs that are technically "compliant" but practically unmaintainable.

Applied thoughtfully, LoD creates systems that are genuinely more resilient, testable, and evolvable. The difference lies in understanding why the principle exists and recognizing when its benefits are outweighed by its costs.

What You Will Learn

This page develops your judgment for applying LoD appropriately. You'll learn where LoD is most valuable, where its application may be relaxed, how to avoid common LoD anti-patterns, and how to balance LoD with other design concerns. By the end, you'll approach LoD as a tool to wield skillfully, not a rule to follow blindly.

Where LoD Provides Maximum Value

Not all code equally benefits from LoD. The principle provides the most value in contexts where its coupling-reduction effect addresses real problems. Understanding these contexts helps you prioritize LoD application where it matters most.

High-Value LoD Application Contexts

•Module boundaries — Where different modules (packages, services, bounded contexts) interact. LoD violations here spread coupling across architectural boundaries, making independent evolution impossible.
•Stable public APIs — Interfaces that external code depends on. LoD-violating APIs force all consumers to update when internals change. Public APIs should expose behavior, not structure.
•Long-lived codebases — Systems expected to evolve over years. Initial LoD investment pays dividends as structure changes don't ripple through accumulated code.
•Multi-team development — When different teams own different components. LoD creates clear contracts that teams can work against independently.
•Heavily-tested code — Tests couple to the interfaces they verify. LoD violations force test rewrites when structure changes, even if behavior doesn't.
•Frequently-changing domains — Areas where requirements evolve regularly. LoD compliance means structure changes don't cascade into unrelated code.

LoD Value Assessment Matrix
Factor	Low LoD Value	High LoD Value
Codebase lifetime	Prototype, short-term project	Production system, multi-year lifespan
Rate of change	Stable, rarely modified	Actively evolving requirements
Team structure	Single developer, small team	Multiple teams, organizational boundaries
API scope	Internal implementation detail	Public API, cross-module interface
Test coverage	Minimal or no tests	Extensive test suite depends on interfaces
Refactoring frequency	Rare restructuring expected	Regular internal refactoring expected

Invest LoD Effort Strategically

Apply LoD rigor at boundaries and public interfaces. Be more pragmatic in implementation details that are contained within a single module and changed together. The cost of LoD enforcement should match the benefit of coupling reduction for that specific context.

Contexts Where LoD May Be Relaxed

Recognizing contexts where strict LoD application provides little value (or creates problems) is equally important. These are situations where the coupling concerns LoD addresses are already managed in other ways, or where the overhead of LoD compliance outweighs benefits.

Lower-Value LoD Contexts

•Data Transfer Objects (DTOs) — Plain data containers with no behavior, designed solely to carry data between layers. They're explicitly structure, not behavior.
•Configuration objects — Nested configuration structures where the entire structure is the interface. config.database.connection.timeout is accessing configuration, not navigating domain objects.
•Test assertions — Test code may navigate into structures to verify state. Tests are coupled to implementation by design; they validate specific internal states.
•Internal module cohesion — Classes within the same cohesive module that change together. Coupling within a single tightly-cohesive unit is expected.
•Data mapping layers — Code explicitly responsible for transforming external structures (API responses, database rows) into domain objects.
•Scripting/glue code — Quick automation scripts, one-off migration tools, or throwaway code with short lifespans.

relaxed-lod-examples.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
// DTO Navigation — Acceptable
// DTOs are data containers; their structure IS their interface
interface OrderDto {
    customer: CustomerDto;
    items: ItemDto[];
    shipping: ShippingDto;
}
 
function displayOrder(dto: OrderDto): void {
    // Navigating DTO structure is expected — DTOs are data, not behavior
    console.log(`Customer: ${dto.customer.name}`);
    console.log(`Items: ${dto.items.length}`);
    console.log(`Ship to: ${dto.shipping.address.city}`);
}
 
 
// Configuration Navigation — Acceptable
// Config structure is stable and environment-defined
interface AppConfig {
    database: {
        host: string;
        port: number;
        connection: {
            timeout: number;
            poolSize: number;
        };
    };
}
 
function initDatabase(config: AppConfig): void {
    // Config navigation is standard; structure matches file/env format
    const timeout = config.database.connection.timeout;
    // ...
}
 
 
// Test Assertion Navigation — Acceptable
// Tests verify internal state by design
describe('Order', () => {
    it('stores customer correctly', () => {
        const order = new Order(customer, items);
        
        // Test navigates to verify internal state
        expect(order.getCustomer().getAddress().getCity())
            .toBe('San Francisco');
    });
});
 
 
// Internal Cohesion — Acceptable at Lower Scale
// Within a single cohesive module, tight coupling is expected
class OrderAggregate {
    private order: Order;
    private payment: Payment;
    private shipping: Shipping;
    
    // These classes all change together, live in same module
    // Internal coupling is acceptable
    calculateTotal(): Money {
        return this.order.subtotal()
            .add(this.shipping.getCost())
            .subtract(this.payment.getAppliedDiscounts());
    }
}

Relaxation Requires Intention

Relaxing LoD should be a conscious decision with clear justification, not an excuse for sloppy code. Ask yourself: "Why doesn't LoD apply here?" If you can't articulate a reason from the list above, you're likely just avoiding the refactoring effort.

Anti-Pattern: Delegation Method Explosion

The most common LoD anti-pattern is delegation method explosion: creating hundreds of pass-through methods that merely forward calls to internal objects. While technically LoD-compliant, this creates worse problems than the violations it prevents.

delegation-explosion.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
// ❌ ANTI-PATTERN: Delegation Method Explosion
// Every Customer method needs a corresponding Order method
 
class Customer {
    getName(): string { ... }
    getEmail(): string { ... }
    getPhone(): string { ... }
    getAddress(): Address { ... }
    getShippingAddress(): Address { ... }
    getBillingAddress(): Address { ... }
    getPreferences(): Preferences { ... }
    getPaymentMethods(): PaymentMethod[] { ... }
    getLoyaltyPoints(): number { ... }
    getMembershipTier(): string { ... }
    getCreatedAt(): Date { ... }
    getLastOrderDate(): Date { ... }
    // ... 20 more methods
}
 
class Order {
    private customer: Customer;
    
    // Now Order has to expose ALL of these
    getCustomerName(): string { return this.customer.getName(); }
    getCustomerEmail(): string { return this.customer.getEmail(); }
    getCustomerPhone(): string { return this.customer.getPhone(); }
    getCustomerAddress(): Address { return this.customer.getAddress(); }
    getCustomerShippingAddress(): Address { return this.customer.getShippingAddress(); }
    getCustomerBillingAddress(): Address { return this.customer.getBillingAddress(); }
    getCustomerPreferences(): Preferences { return this.customer.getPreferences(); }
    getCustomerPaymentMethods(): PaymentMethod[] { return this.customer.getPaymentMethods(); }
    getCustomerLoyaltyPoints(): number { return this.customer.getLoyaltyPoints(); }
    getCustomerMembershipTier(): string { return this.customer.getMembershipTier(); }
    getCustomerCreatedAt(): Date { return this.customer.getCreatedAt(); }
    getCustomerLastOrderDate(): Date { return this.customer.getLastOrderDate(); }
    // ... 20 more delegation methods
    
    // Order's actual behavior is lost in a sea of delegations
}

Why this is harmful:

Bloated interfaces — Order becomes an "API for Customer through Order" instead of "Order's interface"
Maintenance burden — Every new Customer method requires a new Order method
Hidden coupling — Coupling isn't eliminated, just hidden behind delegations
Confused responsibilities — Order does everything Customer does, plus its own work
Discoverability — Finding the right method becomes harder with hundreds of options

The Solution: Behavior-Focused Delegation

Instead of mirroring internal structure, ask: "What behaviors do callers actually need from Order?" Create methods for those behaviors — not pass-throughs for every internal accessor. If callers need general Customer access frequently, perhaps Order should expose getCustomer() directly.

behavior-focused-delegation.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
// ✅ BETTER: Behavior-Focused Delegation
// Order exposes what it DOES, not what it CONTAINS
 
class Order {
    private customer: Customer;
    
    // Expose the FEW behaviors Order callers actually need
    sendConfirmation(): void {
        this.notificationService.send(
            this.customer.getEmail(),
            this.createConfirmationMessage()
        );
    }
    
    getShippingDestination(): ShippingDestination {
        return new ShippingDestination(
            this.customer.getName(),
            this.customer.getShippingAddress()
        );
    }
    
    calculateLoyaltyDiscount(): Money {
        return this.loyaltyProgram.calculateDiscount(
            this.customer.getLoyaltyPoints(),
            this.subtotal
        );
    }
    
    // For cases where Customer access is genuinely needed
    // consider exposing Customer directly
    getCustomer(): Customer {
        return this.customer;  // This is OK if callers work with customers
    }
}
 
// Key insight: Order has 4 intentional points of delegation
// instead of 20+ mechanical mirror methods

Anti-Pattern: Wrapper Overload

Another LoD anti-pattern is wrapper overload: creating layer upon layer of wrapper objects solely to avoid direct access. Each layer adds indirection without adding value, making the code harder to understand and maintain.

wrapper-overload.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
// ❌ ANTI-PATTERN: Wrapper Overload
// Unnecessary layers just to avoid 'getCustomer().getAddress()'
 
// Original structure
order.getCustomer().getAddress().getCity();
 
// "LoD-compliant" wrapper approach (wrong)
class OrderCustomerWrapper {
    constructor(private customer: Customer) {}
    
    getAddressWrapper(): CustomerAddressWrapper {
        return new CustomerAddressWrapper(this.customer.getAddress());
    }
}
 
class CustomerAddressWrapper {
    constructor(private address: Address) {}
    
    getCity(): string {
        return this.address.getCity();
    }
}
 
class Order {
    getCustomerWrapper(): OrderCustomerWrapper {
        return new OrderCustomerWrapper(this.customer);
    }
}
 
// Usage
order.getCustomerWrapper().getAddressWrapper().getCity();
 
// What went wrong?
// - Same navigation, just more complex
// - Added maintenance burden (3 new classes)
// - Coupling not reduced, just obscured
// - Worse readability than original

proper-encapsulation.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
// ✅ CORRECT APPROACH: Proper Encapsulation
// Identify the actual behavior needed and encapsulate it
 
class Order {
    // What behavior does the caller actually need?
    // They need the shipping city for zone calculation
    
    getShippingCity(): string {
        return this.customer.getShippingCity();
    }
}
 
class Customer {
    getShippingCity(): string {
        return this.address.getCity();
    }
}
 
// Usage
order.getShippingCity();
 
// What's better?
// - No new wrapper classes
// - Clear, intentional API
// - Behavior is where it belongs
// - Internal structure is hidden

Wrappers vs. Adapters

Wrappers that add value (adapters for external APIs, decorators for behavior modification, facades for simplification) are legitimate. Wrappers that merely hide navigation without adding behavior are overhead. Ask: "Does this wrapper DO anything, or just forward calls?"

Balancing LoD with Other Design Principles

Design principles can conflict. Strict LoD adherence might violate simplicity (KISS), create premature abstraction (YAGNI), or require restructuring that conflicts with cohesion. Balancing these principles requires judgment about which concerns matter most in each specific context.

LoD Tensions with Other Principles
Principle	Potential Conflict	Balance Strategy
KISS (Keep It Simple)	Delegation methods add complexity	Only add delegations for frequently-used behaviors
YAGNI (You Aren't Gonna Need It)	Preemptive LoD compliance may over-engineer	Apply LoD as coupling problems emerge, not speculatively
DRY (Don't Repeat Yourself)	Multiple delegation methods may duplicate structure	Use parameter objects or interfaces to factor common needs
Single Responsibility	LoD may cause objects to know about more concerns	Ensure delegations align with object's core responsibility
Performance	Delegation adds call overhead	In hot paths, consider acceptable violations with documentation
Readability	Deep delegation chains obscure what's happening	Balance encapsulation with clarity; document complex flows

balancing-examples.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
// LoD vs KISS
// LoD-pure but complex
order.getConfirmationDetails().getRecipient().getEmailAddress();
 
// KISS-preferred, mild LoD bend
const customer = order.getCustomer();
sendConfirmation(customer.getEmail(), customer.getName());
 
 
// LoD vs YAGNI
// Premature LoD compliance (YAGNI violation)
class Order {
    // Added "just in case" someone needs logging format
    getCustomerLogFormat(): string { ... }
    // Added "just in case" someone needs short format  
    getCustomerShortName(): string { ... }
    // Added "just in case"...
    getCustomerFullDetails(): CustomerDetails { ... }
}
 
// YAGNI-compliant approach
class Order {
    // Add delegation methods when actual callers need them
    // Until then, expose getCustomer() if needed
    getCustomer(): Customer { return this.customer; }
}
 
 
// LoD vs Performance (rare but real)
// In a tight loop processing millions of records
for (const record of millionRecords) {
    // LoD-compliant: multiple method calls
    process(record.getX(), record.getY(), record.getZ());
    
    // Performance-optimized: direct access (with documentation)
    // Note: Violating LoD for performance in hot path
    process(record.data.x, record.data.y, record.data.z);
}

The Prioritization Heuristic

When principles conflict, consider: (1) What problem actually exists now? (2) What's the cost of each approach? (3) What's most likely to change? Favor the approach that solves real problems with minimal ceremony. Design principles exist to serve good design, not the other way around.

The Middle Ground — Practical LoD

Between strict LoD enforcement and complete abandonment lies a practical middle ground that most successful codebases inhabit. This approach applies LoD thoughtfully based on context rather than dogmatically.

Practical LoD Guidelines

•One navigation level is often acceptable. order.getCustomer().getName() is usually fine. order.getCustomer().getAddress().getCity().getShippingZone() is not. The deeper you go, the more coupling you create.
•Behavior access is better than data access. order.getCustomer().sendNotification() is better than order.getCustomer().getEmail() then manually sending. Push behavior to data.
•Consider frequency and stability. Navigation through stable structures (rare changes, well-defined contracts) is lower risk than navigation through volatile structures.
•Boundaries matter most. Apply LoD strictly at module/service boundaries. Be more flexible within cohesive internal units.
•If you expose it, own it. If you decide to expose internal structure, you're committing to maintain that structure. Make explicit choices.
•Test impact is telling. If LoD violations make tests brittle (breaking for structure changes, not behavior changes), the coupling is problematic.

Too Strict

•Delegation method for every internal accessor
•Wrapper classes that just forward calls
•Never navigating any object graph
•Treating DTOs like domain objects
•Creating interfaces for single implementations
•Absolute zero dots except on this

Practical Balance

•Delegation methods for actual needed behaviors
•Direct access where coupling is intentional
•Shallow navigation in low-risk contexts
•DTOs accessed as data structures
•Abstraction where variation/change expected
•Context-appropriate LoD strictness

The Rule of Thumb

Ask yourself: "If the internal structure of this object changed, would I be surprised if my code broke?" If yes, you're probably navigating too deeply. If no (because the structure is stable, intentionally exposed, or within your own module), the navigation may be acceptable.

LoD Across Programming Paradigms

LoD was formulated for object-oriented programming, but its core insight — limiting knowledge between components — applies across paradigms. Understanding how LoD translates helps you apply its principles consistently regardless of the technology stack.

LoD in Object-Oriented Programming

•Classic LoD: methods should only call methods on immediate collaborators
•Encapsulation and information hiding are direct goals
•Navigation through object graphs is the primary violation pattern

LoD in Functional Programming

•Functions should only use values they receive as arguments
•Avoid reaching into nested data structures passed to functions
•Prefer lens/optics abstractions for deep data access
•Composition replaces navigation: pass the value you need, not the container

functional-lod.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// LoD in Functional Style
 
// ❌ LoD violation: function reaches into passed structure
function formatShipping(order: Order): string {
    // Reaching into order's structure
    const city = order.customer.address.city;
    return `Ships to: ${city}`;
}
 
// ✅ LoD compliant: function receives what it needs
function formatShipping(cityName: string): string {
    return `Ships to: ${cityName}`;
}
 
// Caller provides the value:
formatShipping(order.getShippingCityName());
 
// Alternative: use lenses for structured access
const shippingCityLens = compose(
    orderCustomerLens,
    customerAddressLens,
    addressCityLens
);
 
const cityName = view(shippingCityLens, order);

LoD in Microservices/Distributed Systems

•Services should only call services they directly depend on
•Avoid service orchestration that reaches through intermediaries
•Choreography (events) often more LoD-compliant than orchestration (commands)
•API Gateway pattern can provide facades that contain navigation

microservices-lod.txt

❌ LoD Violation at Service Level:
OrderService → CustomerService → AddressService → GeoService
 
OrderService orchestrates calls across three services to get shipping zone
Any service API change breaks the entire flow
 
 
✅ LoD Compliant at Service Level:
OrderService → ShippingService
 
ShippingService internally aggregates what it needs from other services
OrderService only knows about ShippingService
Internal service changes don't affect OrderService

The Universal Principle

Regardless of paradigm, LoD's essence is: components should have minimal knowledge of other components' internal structure. Whether you're navigating objects, reaching into data structures, or orchestrating service calls, limiting what each component "knows" reduces coupling and increases flexibility.

Code Review Checklist for LoD

When reviewing code for LoD compliance, use this systematic checklist. It helps distinguish problematic violations from acceptable patterns and provides actionable feedback.

LoD Review Checklist

•Identify chain length. How many navigation levels deep does the code go? One level is usually fine; three or more warrants scrutiny.
•Check chain purpose. Is this navigation (accessing structure) or transformation (processing values)? Transformation chains are acceptable.
•Assess boundary context. Is this code at a module/service boundary or internal to a cohesive unit? Boundaries need strict LoD.
•Consider change likelihood. How stable is the structure being navigated? Volatile structures are high-risk coupling points.
•Evaluate alternatives. Could the needed data/behavior be provided by the direct dependency instead? Suggest refactoring if so.
•Check test impact. Would this navigation make tests brittle to structure changes? If tests would break for non-behavior reasons, that's a smell.
•Look for patterns. Is this navigation pattern repeated elsewhere? Repeated navigation suggests missing abstraction.
•Consider documentation. If violations are intentional (DTOs, performance), are they documented as such?

code-review-examples.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
// Review Example 1
order.getCustomer().getEmail();
 
// Checklist application:
// 1. Chain length: 2 levels ✓
// 2. Purpose: Navigation (accessing email from customer) ⚠️
// 3. Boundary: Depends on context
// 4. Stability: Customer-has-Email is stable ✓
// 5. Alternative: Could Order provide getCustomerEmail()? Maybe.
// 6. Test impact: Low — structure is stable
// 7. Pattern: Check if repeated — if so, add delegation
// 8. Documentation: N/A
 
// VERDICT: Borderline. Acceptable in implementation code,
// worth adding delegation if used frequently.
 
 
// Review Example 2
order.getCustomer().getWallet().getCreditCard().getNetwork().validateForMerchant();
 
// Checklist application:
// 1. Chain length: 5 levels ❌
// 2. Purpose: Deep navigation ❌
// 3. Boundary: Likely crossing domain boundaries
// 4. Stability: Wallet/CreditCard/Network structure is volatile
// 5. Alternative: order.validatePaymentMethod() would encapsulate ✓
// 6. Test impact: Would require complex mock setup
// 7. Pattern: Payment validation likely repeated
// 8. Documentation: Not documented as intentional
 
// VERDICT: Clear violation. Refactor to encapsulate validation.

Summary — Demeter Applied Wisely

We've explored the nuanced art of applying the Law of Demeter appropriately. The goal is not blind adherence but informed judgment — understanding when LoD provides value and when its costs outweigh benefits.

Key Takeaways

•LoD value varies by context. Apply strictly at boundaries and public APIs. Be more pragmatic in internal code that changes together.
•Some contexts don't need strict LoD. DTOs, configuration, test assertions, and internal cohesive units may reasonably navigate structure.
•Avoid anti-patterns. Delegation method explosion and wrapper overload are worse than the violations they prevent. Focus on behavior, not mechanical forwarding.
•Balance with other principles. LoD can conflict with KISS, YAGNI, and simplicity. Favor solutions that solve real problems without excessive ceremony.
•Practical middle ground exists. One navigation level is often acceptable. Deep navigation is problematic. Context determines appropriate depth.
•LoD applies across paradigms. Whether OOP, FP, or microservices, the principle of limiting component knowledge about other components' internals applies.
•Use the code review checklist. Systematically evaluate chains for length, purpose, boundary context, stability, and alternatives.

Module Complete

You've completed the Law of Demeter module. You now understand: the formal definition and rationale ("talk only to friends"), how LoD reduces coupling through firebreaks, the distinction between navigation chains (violations) and transformation chains (compliant), and how to apply LoD appropriately based on context. This principle, combined with the others in this chapter, forms a foundation for designing maintainable, evolvable object-oriented systems.