Delegation Pattern - Learning Module

Loading content...

0/246

Implementing Delegation

From Concept to Production Code

We've established what delegation is, how it works mechanically, and when to prefer it over inheritance. Now we turn to the practical question: How do you implement delegation effectively in real production codebases?

Effective implementation goes beyond knowing the concept. It requires understanding idioms, recognizing patterns, avoiding common pitfalls, and organizing code for clarity and maintainability. This page provides the practical guidance you need to implement delegation like an experienced architect.

We'll examine concrete implementation patterns, discuss code organization, explore common mistakes, and provide a checklist for delegation done right.

What You Will Learn

By the end of this page, you will know how to structure delegation in your code, follow established patterns for common scenarios, avoid typical mistakes, and apply a practical checklist for implementing delegation correctly. You'll be ready to apply delegation confidently in production systems.

The Standard Delegation Structure

Most delegation follows a standard structure. Understanding this template helps you implement delegation consistently:

The Three Components:

Interface (Protocol) — Defines what can be delegated. This is the contract between delegator and delegate.
Delegate Implementations — Concrete classes that implement the interface, providing different behaviors.
Delegator — The class that uses delegates, forwarding requests through the interface.

Let's see this structure in a complete example:

standard-delegation-structure
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
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
// ============================================
// COMPONENT 1: THE INTERFACE (PROTOCOL)
// ============================================
// Defines the contract for delegation
// Keep it focused—one responsibility per interface
 
interface NotificationSender {
    /**
     * Sends a notification to the specified recipient.
     * @param recipient - The notification target
     * @param message - The notification content
     * @returns true if sent successfully
     */
    send(recipient: string, message: string): Promise<boolean>;
}
 
// ============================================
// COMPONENT 2: DELEGATE IMPLEMENTATIONS
// ============================================
// Multiple implementations of the same interface
// Each encapsulates a different behavior
 
class EmailNotificationSender implements NotificationSender {
    constructor(private emailClient: EmailClient) {}
    
    async send(recipient: string, message: string): Promise<boolean> {
        try {
            await this.emailClient.sendEmail({
                to: recipient,
                subject: 'Notification',
                body: message
            });
            return true;
        } catch (error) {
            console.error('Email send failed:', error);
            return false;
        }
    }
}
 
class SMSNotificationSender implements NotificationSender {
    constructor(private smsGateway: SMSGateway) {}
    
    async send(recipient: string, message: string): Promise<boolean> {
        try {
            await this.smsGateway.sendSMS(recipient, message);
            return true;
        } catch (error) {
            console.error('SMS send failed:', error);
            return false;
        }
    }
}
 
class SlackNotificationSender implements NotificationSender {
    constructor(private slackClient: SlackClient) {}
    
    async send(recipient: string, message: string): Promise<boolean> {
        try {
            await this.slackClient.postMessage(recipient, message);
            return true;
        } catch (error) {
            console.error('Slack send failed:', error);
            return false;
        }
    }
}
 
// ============================================
// COMPONENT 3: THE DELEGATOR
// ============================================
// Uses the interface, not concrete implementations
// Receives delegate via constructor injection
 
class NotificationService {
    constructor(private sender: NotificationSender) {}
    
    async notifyUser(userId: string, event: UserEvent): Promise<void> {
        const user = await this.getUserDetails(userId);
        const message = this.formatMessage(event);
        
        // DELEGATION: Forward to the injected sender
        const success = await this.sender.send(user.contactInfo, message);
        
        if (!success) {
            await this.logFailure(userId, event);
        }
    }
    
    private async getUserDetails(userId: string): Promise<User> {
        // ... fetch user
    }
    
    private formatMessage(event: UserEvent): string {
        return `Event: ${event.type} - ${event.description}`;
    }
    
    private async logFailure(userId: string, event: UserEvent): Promise<void> {
        // ... log for retry
    }
}
 
// ============================================
// USAGE: WIRING IT TOGETHER
// ============================================
// Create delegates and inject into delegator
 
// Production
const emailSender = new EmailNotificationSender(new RealEmailClient());
const notificationService = new NotificationService(emailSender);
 
// Or use SMS
const smsSender = new SMSNotificationSender(new TwilioGateway());
const smsNotificationService = new NotificationService(smsSender);
 
// Testing
const mockSender: NotificationSender = { send: jest.fn() };
const testService = new NotificationService(mockSender);

The Pattern at a Glance

Interface defines WHAT. Delegates define HOW (various implementations). Delegator uses WHICH (injected at construction). This separation is the heart of effective delegation.

Dependency Injection Patterns

Delegation and dependency injection (DI) are natural partners. DI provides the mechanism for supplying delegates to delegators. Let's examine the patterns:

Pattern 1: Constructor Injection (Preferred)

Provide all required delegates through the constructor:

class OrderService {
    constructor(
        private paymentProcessor: PaymentProcessor,
        private inventoryManager: InventoryManager,
        private notificationService: NotificationService
    ) {}
}

Advantages:

All dependencies visible at construction
Object is fully initialized immediately
Dependencies are immutable (can be readonly/final)
Easy to see what the class needs

Pattern 2: Property/Setter Injection

For optional dependencies or when runtime changes are needed:

class ReportGenerator {
    private formatter?: ReportFormatter;
    
    setFormatter(formatter: ReportFormatter): void {
        this.formatter = formatter;
    }
    
    generate(data: ReportData): Report {
        const formatter = this.formatter ?? new DefaultFormatter();
        return formatter.format(data);
    }
}

Use when:

Dependency is optional (has a default)
Dependency should be changeable after construction
Circular dependencies require it (rare, often a design smell)

Dependency Injection Pattern Comparison
Pattern	Use Case	Immutability	Testability
Constructor	Required dependencies	Supported (readonly)	Excellent
Setter	Optional dependencies	Not supported	Good
Method	Per-call variation	N/A (transient)	Excellent
Factory	Lazy/conditional creation	Depends	Good (inject factory)

Pattern 3: Method Injection

Pass the delegate as a parameter to specific methods:

class DataExporter {
    export(data: Data, formatter: DataFormatter): string {
        return formatter.format(data);
    }
}

// Different formatters for different calls
exporter.export(data, new JSONFormatter());
exporter.export(data, new CSVFormatter());

Use when:

Different delegates needed for different calls
Delegate is truly specific to one operation
No persistent delegate relationship needed

Pattern 4: Container/Framework Injection

Let a DI container wire dependencies:

// Definition (e.g., in a module)
@Injectable()
class OrderService {
    constructor(
        @Inject(PAYMENT_PROCESSOR) private paymentProcessor: PaymentProcessor,
        @Inject(INVENTORY_MANAGER) private inventoryManager: InventoryManager
    ) {}
}

// Registration
container.register(PAYMENT_PROCESSOR, StripePaymentProcessor);
container.register(INVENTORY_MANAGER, WarehouseInventoryManager);

// Resolution
const orderService = container.resolve(OrderService);

Advantages:

Centralized configuration
Lifecycle management
Easier to change implementations globally

DI Containers Are Optional

You don't need a DI framework to use dependency injection. Manual "poor man's DI" (just passing dependencies to constructors) works fine for smaller codebases. DI containers help manage complexity at scale, but the principle of injection applies regardless of tooling.

Composite Delegation Patterns

Sometimes you need to delegate to multiple objects of the same type, or chain delegates together. Here are patterns for complex delegation scenarios:

Pattern 1: Composite Delegate (Broadcast)

Delegate to multiple implementations, combining their results:

interface EventListener {
    onEvent(event: Event): void;
}

class CompositeEventListener implements EventListener {
    private listeners: EventListener[] = [];
    
    addListener(listener: EventListener): void {
        this.listeners.push(listener);
    }
    
    onEvent(event: Event): void {
        // Delegate to ALL listeners
        for (const listener of this.listeners) {
            listener.onEvent(event);
        }
    }
}

The composite itself implements the interface, so it can be used wherever a single delegate is expected. Clients don't know they're talking to a composite.

composite-delegation-patterns
TypeScript
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
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
// Pattern 2: Chain of Responsibility
// Delegate until one handler succeeds
 
interface RequestHandler {
    handle(request: Request): Response | null;
}
 
class HandlerChain implements RequestHandler {
    private handlers: RequestHandler[] = [];
    
    addHandler(handler: RequestHandler): void {
        this.handlers.push(handler);
    }
    
    handle(request: Request): Response | null {
        for (const handler of this.handlers) {
            const response = handler.handle(request);
            if (response !== null) {
                return response;  // First handler that responds wins
            }
        }
        return null;  // No handler could process
    }
}
 
// Concrete handlers
class AuthHandler implements RequestHandler {
    handle(request: Request): Response | null {
        if (request.path.startsWith('/auth')) {
            return this.processAuth(request);
        }
        return null;  // Pass to next handler
    }
}
 
class APIHandler implements RequestHandler {
    handle(request: Request): Response | null {
        if (request.path.startsWith('/api')) {
            return this.processAPI(request);
        }
        return null;
    }
}
 
// Usage
const chain = new HandlerChain();
chain.addHandler(new AuthHandler());
chain.addHandler(new APIHandler());
chain.addHandler(new StaticFileHandler());  // Fallback
 
const response = chain.handle(incomingRequest);
 
 
// Pattern 3: Decorator Chain
// Each delegate wraps the next, adding behavior
 
interface DataProcessor {
    process(data: string): string;
}
 
class BaseProcessor implements DataProcessor {
    process(data: string): string {
        return data;  // Identity—just return data
    }
}
 
class ValidationDecorator implements DataProcessor {
    constructor(private wrapped: DataProcessor) {}
    
    process(data: string): string {
        if (!data || data.length === 0) {
            throw new Error('Empty data');
        }
        return this.wrapped.process(data);
    }
}
 
class LoggingDecorator implements DataProcessor {
    constructor(private wrapped: DataProcessor) {}
    
    process(data: string): string {
        console.log('Processing:', data.substring(0, 50));
        const result = this.wrapped.process(data);
        console.log('Result:', result.substring(0, 50));
        return result;
    }
}
 
class CompressionDecorator implements DataProcessor {
    constructor(private wrapped: DataProcessor) {}
    
    process(data: string): string {
        const processed = this.wrapped.process(data);
        return compress(processed);
    }
}
 
// Build a chain of decorators
const processor: DataProcessor = 
    new LoggingDecorator(
        new ValidationDecorator(
            new CompressionDecorator(
                new BaseProcessor()
            )
        )
    );
 
// Each layer delegates to the next while adding its behavior
const result = processor.process(inputData);

Pattern 3: Strategy Selection

Choose among delegates based on context:

class PaymentProcessor {
    private strategies: Map<PaymentMethod, PaymentStrategy> = new Map();
    
    registerStrategy(method: PaymentMethod, strategy: PaymentStrategy): void {
        this.strategies.set(method, strategy);
    }
    
    process(payment: Payment): Result {
        const strategy = this.strategies.get(payment.method);
        if (!strategy) {
            throw new Error(`No strategy for ${payment.method}`);
        }
        return strategy.process(payment);  // Delegate to selected strategy
    }
}

// Register strategies
processor.registerStrategy(PaymentMethod.CARD, new CardStrategy());
processor.registerStrategy(PaymentMethod.BANK, new BankTransferStrategy());
processor.registerStrategy(PaymentMethod.CRYPTO, new CryptoStrategy());

Composition of Composition

These patterns show how delegation scales. Composites, chains, and decorators can themselves be delegates. You can build arbitrarily complex behavior from simple, focused components—each following the same delegation principles.

The Null Object Pattern

When delegates are optional, you often need to handle the "no delegate" case. The Null Object pattern provides an elegant solution by implementing a delegate that does nothing—avoiding null checks throughout your code.

The Problem:

class Logger {
    private formatter?: Formatter;
    
    log(message: string): void {
        // Null check everywhere!
        const formatted = this.formatter 
            ? this.formatter.format(message) 
            : message;
        console.log(formatted);
    }
}

The Solution: Null Object

interface Formatter {
    format(message: string): string;
}

// Null Object—does nothing, returns input unchanged
class NullFormatter implements Formatter {
    format(message: string): string {
        return message;  // Identity—no formatting
    }
}

class Logger {
    private formatter: Formatter;  // Never null!
    
    constructor(formatter: Formatter = new NullFormatter()) {
        this.formatter = formatter;
    }
    
    log(message: string): void {
        // No null check needed—delegation just works
        const formatted = this.formatter.format(message);
        console.log(formatted);
    }
}

null-object-examples
TypeScript
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
65
66
67
// More Null Object Examples
 
// Null Logger—silently ignores all log calls
interface Logger {
    log(level: LogLevel, message: string): void;
    error(message: string, error?: Error): void;
}
 
class NullLogger implements Logger {
    log(level: LogLevel, message: string): void {
        // Do nothing
    }
    
    error(message: string, error?: Error): void {
        // Do nothing
    }
}
 
// Use when logging should be disabled
const silentService = new DataService(new NullLogger());
 
 
// Null Cache—always misses, never stores
interface Cache<T> {
    get(key: string): T | undefined;
    set(key: string, value: T): void;
}
 
class NullCache<T> implements Cache<T> {
    get(key: string): T | undefined {
        return undefined;  // Always cache miss
    }
    
    set(key: string, value: T): void {
        // Do nothing—don't store
    }
}
 
// Use when caching should be disabled
const uncachedService = new UserService(new NullCache<User>());
 
 
// Null Validator—always passes
interface Validator<T> {
    validate(value: T): ValidationResult;
}
 
class NullValidator<T> implements Validator<T> {
    validate(value: T): ValidationResult {
        return { valid: true, errors: [] };  // Always valid
    }
}
 
// Use when validation should be skipped
const trustingService = new FormHandler(new NullValidator<FormData>());
 
 
// Null Event Publisher—events disappear
interface EventPublisher {
    publish(event: Event): Promise<void>;
}
 
class NullEventPublisher implements EventPublisher {
    async publish(event: Event): Promise<void> {
        // Event is silently dropped
    }
}

Benefits of Null Object Pattern

•Eliminates null checks — No more if (delegate !== null) scattered through code.
•Uniform delegation — Every path goes through delegation; no special cases.
•Simplifies client code — Clients don't need to know if the delegate is "real" or null.
•Enables opt-out behavior — Provides a way to disable features without conditionals.
•Testing helper — Use null objects when you don't care about a particular delegate's behavior.

Singleton Null Objects

Since null objects are stateless, you can make them singletons to avoid creating redundant instances. Export a shared instance: export const NULL_LOGGER = new NullLogger();

Common Implementation Mistakes

Even with good intentions, delegation can be implemented poorly. Here are common mistakes and how to avoid them:

Mistake 1: Internal Instantiation of Delegates

// BAD: Tight coupling, untestable
class OrderService {
    private paymentGateway = new StripePaymentGateway();  // Hardcoded!
}

// GOOD: Injected dependency
class OrderService {
    constructor(private paymentGateway: PaymentGateway) {}  // Interface
}

Why it's bad: You can't substitute different implementations, can't mock for testing, and are tightly coupled to a specific concrete class.

Mistake 2: Depending on Concrete Classes Instead of Interfaces

// BAD: Depends on concrete class
class ReportGenerator {
    constructor(private formatter: PDFFormatter) {}  // Concrete!
}

// GOOD: Depends on interface
class ReportGenerator {
    constructor(private formatter: ReportFormatter) {}  // Interface
}

Why it's bad: Defeats the purpose of delegation—you're still coupled to a specific implementation.

Delegation Anti-Patterns to Avoid

•Internal instantiation — Always inject delegates; never new ConcreteDelegate() inside the delegator.
•Concrete dependencies — Depend on interfaces, not concrete classes.
•Leaky abstractions — Don't let delegate implementation details leak into the delegator.
•Fat interfaces — Keep delegate interfaces focused; avoid kitchen-sink interfaces.
•Null checks everywhere — Use Null Object pattern instead of checking if (delegate !== null).
•Exposing delegate directly — Don't return your internal delegate; it breaks encapsulation.
•Optional injection without defaults — If a delegate is optional, provide a Null Object default.

Mistake 3: Leaking Delegate Implementation Details

// BAD: Exposes how delegate works internally
class DocumentService {
    getDocument(id: string): Document {
        const rawData = this.storage.getRawBytes(id);  // Storage detail
        const checksum = this.storage.getChecksum(id);  // Storage detail
        // ... process using storage internals
    }
}

// GOOD: Uses delegate at the right abstraction level
class DocumentService {
    getDocument(id: string): Document {
        return this.storage.retrieveDocument(id);  // Appropriate abstraction
    }
}

Mistake 4: Exposing Internal Delegates

// BAD: Breaks encapsulation
class Car {
    getEngine(): Engine {
        return this.engine;  // Exposes internal!
    }
}

// Caller can now: car.getEngine().overheat();  // Bypasses Car!

// GOOD: Expose capabilities, not internals
class Car {
    startEngine(): void {
        this.engine.start();
    }
    
    getEngineStatus(): EngineStatus {
        return this.engine.getStatus();  // Read-only info, not the engine itself
    }
}

The "Getter" Smell

If you find yourself adding getDelegate() methods, pause and ask why the caller needs direct access. Usually, the delegator should expose methods that use the delegate, not the delegate itself. "Tell, Don't Ask" applies here.

Code Organization for Delegation

How you organize delegation-heavy code affects maintainability. Here are proven organizational patterns:

Pattern 1: Interfaces Near Consumers

Place interfaces close to where they're used (in the consumer's module), not with implementations:

src/
  orders/
    OrderService.ts       # Delegator
    PaymentGateway.ts     # Interface (defined here, used here)
  payments/
    StripeGateway.ts      # Implementation of PaymentGateway
    PayPalGateway.ts      # Another implementation

Why: The interface is part of the Order module's contract. Payment implementations depend on the interface, not the other way around. This follows the Dependency Inversion Principle.

Pattern 2: Separate Interface Packages

For shared interfaces used across multiple modules:

src/
  interfaces/
    PaymentGateway.ts
    NotificationSender.ts
  orders/
    OrderService.ts
  payments/
    StripeGateway.ts
  notifications/
    EmailSender.ts

module-organization
TypeScript
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
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
// Pattern 3: Feature-Based Organization
// Group by feature, with clear internal structure
 
// src/orders/
// ├── index.ts                  # Public exports
// ├── OrderService.ts           # Main service (delegator)
// ├── types.ts                  # Interfaces this module defines
// │   └── PaymentProcessor.ts   # Interface for payment delegation
// │   └── InventoryChecker.ts   # Interface for inventory delegation
// └── testing/
//     └── mocks.ts              # Mock implementations for testing
 
// src/orders/types.ts
export interface PaymentProcessor {
    process(amount: Money): Promise<PaymentResult>;
}
 
export interface InventoryChecker {
    check(items: OrderItem[]): Promise<InventoryStatus>;
}
 
// src/orders/OrderService.ts
import { PaymentProcessor, InventoryChecker } from './types';
 
export class OrderService {
    constructor(
        private paymentProcessor: PaymentProcessor,
        private inventoryChecker: InventoryChecker
    ) {}
    
    // ... implementation
}
 
// src/orders/testing/mocks.ts
import { PaymentProcessor, InventoryChecker } from '../types';
 
export class MockPaymentProcessor implements PaymentProcessor {
    public lastAmount?: Money;
    
    async process(amount: Money): Promise<PaymentResult> {
        this.lastAmount = amount;
        return { success: true };
    }
}
 
// src/orders/index.ts
export { OrderService } from './OrderService';
export type { PaymentProcessor, InventoryChecker } from './types';
// Don't export mocks from main index—separate test imports
 
 
// Pattern 4: Composition Root
// Central place where all delegation wiring happens
 
// src/composition-root.ts
import { OrderService } from './orders';
import { StripePaymentProcessor } from './payments/stripe';
import { WarehouseInventoryChecker } from './inventory/warehouse';
import { EmailNotificationSender } from './notifications/email';
 
export function createOrderService(): OrderService {
    return new OrderService(
        new StripePaymentProcessor(config.stripe),
        new WarehouseInventoryChecker(config.warehouse)
    );
}
 
export function createNotificationService(): NotificationService {
    return new NotificationService(
        new EmailNotificationSender(config.email)
    );
}
 
// Entry point uses composition root
// src/main.ts
import { createOrderService, createNotificationService } from './composition-root';
 
const orderService = createOrderService();
const notificationService = createNotificationService();

Pattern 4: Composition Root

Have a single location (the "composition root") where all delegation wiring happens:

Entry point or startup code creates all objects
Dependencies are wired together in one place
No new ConcreteDelegate() scattered throughout codebase
Easy to see and modify the overall wiring

This pattern is especially valuable in larger applications and aligns well with DI containers.

Keep Interfaces Stable

Interfaces are contracts. Changing them affects all implementations. Design interfaces carefully, keep them minimal, and version them if breaking changes are needed. Stable interfaces enable independent evolution of components.

Delegation Implementation Checklist

Use this checklist when implementing delegation to ensure you're following best practices:

Before Implementation:

Pre-Implementation Checklist

•☐ Identified the varying behavior — What specifically will be delegated?
•☐ Defined a focused interface — Does it have a single responsibility?
•☐ Named the interface appropriately — Does the name describe the role/capability?
•☐ Considered multiple implementations — Are there at least two conceivable implementations?
•☐ Checked for existing interfaces — Can you reuse an existing interface?

Implementation Checklist

•☐ Delegate via interface — Delegator depends on interface, not concrete class
•☐ Inject via constructor — Required delegates injected at construction
•☐ Immutable reference — Delegate reference is readonly/final when appropriate
•☐ No internal instantiation — Never new ConcreteDelegate() in the delegator
•☐ Null object for optional — Use Null Object pattern if delegate is optional
•☐ Clear forwarding — Delegation calls are obvious and intentional
•☐ Appropriate abstraction level — Interface matches delegator's abstraction level

Post-Implementation Checklist

•☐ Testable — Can you test the delegator with a mock delegate?
•☐ Documented — Is the interface contract clear (parameters, return values, errors)?
•☐ Encapsulated — Delegate's internals hidden; no leaky abstractions?
•☐ Swappable — Can you easily switch to a different implementation?
•☐ Organized — Are interfaces and implementations in sensible locations?
•☐ Wired correctly — Is composition root or DI container configured properly?

Review Before PR

Before submitting code with new delegation, walk through this checklist. Catching issues before code review saves everyone time and results in better designs reaching production.

Summary: Implementing Delegation

We've covered comprehensive guidance for implementing delegation effectively. Let's consolidate the key insights:

Key Takeaways

•Standard structure — Interface defines contract; delegates implement; delegator uses via injection.
•Dependency injection — Prefer constructor injection; use setters for optional delegates; consider DI containers for larger systems.
•Composite patterns — Use Composite for broadcast, Chain of Responsibility for sequential handling, Decorator for layered behavior.
•Null Object pattern — Eliminate null checks by providing a do-nothing implementation.
•Avoid common mistakes — No internal instantiation, depend on interfaces, don't leak abstractions, don't expose delegates.
•Code organization — Interfaces near consumers, composition root for wiring, feature-based module structure.
•Use the checklist — Systematic verification catches issues before they reach production.

Module Complete

With this page, we've completed our exploration of the Delegation Pattern. You now understand:

What delegation is and why it matters
How to forward requests to contained objects effectively
When to choose delegation over inheritance
How to implement delegation with production-quality code

Delegation, combined with composition, provides the flexibility that rigid inheritance hierarchies cannot match. As you apply these patterns, you'll find your designs becoming more adaptable, more testable, and more maintainable.

In the Next Module:

We'll examine When to Use Inheritance vs Composition—a decision framework that synthesizes everything we've learned about these related but distinct techniques, helping you make confident design decisions in any situation.

Module Complete

Congratulations! You've mastered the Delegation Pattern—from foundational concepts through practical implementation. Delegation is a cornerstone of flexible object-oriented design. Combined with the composition principles from earlier in this chapter, you now have the tools to build systems that adapt to changing requirements without the fragility of rigid inheritance hierarchies.

Implementing Delegation

From Concept to Production Code

We'll examine concrete implementation patterns, discuss code organization, explore common mistakes, and provide a checklist for delegation done right.

What You Will Learn

The Standard Delegation Structure

Most delegation follows a standard structure. Understanding this template helps you implement delegation consistently:

The Three Components:

Interface (Protocol) — Defines what can be delegated. This is the contract between delegator and delegate.
Delegate Implementations — Concrete classes that implement the interface, providing different behaviors.
Delegator — The class that uses delegates, forwarding requests through the interface.

Let's see this structure in a complete example:

standard-delegation-structure
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
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
// ============================================
// COMPONENT 1: THE INTERFACE (PROTOCOL)
// ============================================
// Defines the contract for delegation
// Keep it focused—one responsibility per interface
 
interface NotificationSender {
    /**
     * Sends a notification to the specified recipient.
     * @param recipient - The notification target
     * @param message - The notification content
     * @returns true if sent successfully
     */
    send(recipient: string, message: string): Promise<boolean>;
}
 
// ============================================
// COMPONENT 2: DELEGATE IMPLEMENTATIONS
// ============================================
// Multiple implementations of the same interface
// Each encapsulates a different behavior
 
class EmailNotificationSender implements NotificationSender {
    constructor(private emailClient: EmailClient) {}
    
    async send(recipient: string, message: string): Promise<boolean> {
        try {
            await this.emailClient.sendEmail({
                to: recipient,
                subject: 'Notification',
                body: message
            });
            return true;
        } catch (error) {
            console.error('Email send failed:', error);
            return false;
        }
    }
}
 
class SMSNotificationSender implements NotificationSender {
    constructor(private smsGateway: SMSGateway) {}
    
    async send(recipient: string, message: string): Promise<boolean> {
        try {
            await this.smsGateway.sendSMS(recipient, message);
            return true;
        } catch (error) {
            console.error('SMS send failed:', error);
            return false;
        }
    }
}
 
class SlackNotificationSender implements NotificationSender {
    constructor(private slackClient: SlackClient) {}
    
    async send(recipient: string, message: string): Promise<boolean> {
        try {
            await this.slackClient.postMessage(recipient, message);
            return true;
        } catch (error) {
            console.error('Slack send failed:', error);
            return false;
        }
    }
}
 
// ============================================
// COMPONENT 3: THE DELEGATOR
// ============================================
// Uses the interface, not concrete implementations
// Receives delegate via constructor injection
 
class NotificationService {
    constructor(private sender: NotificationSender) {}
    
    async notifyUser(userId: string, event: UserEvent): Promise<void> {
        const user = await this.getUserDetails(userId);
        const message = this.formatMessage(event);
        
        // DELEGATION: Forward to the injected sender
        const success = await this.sender.send(user.contactInfo, message);
        
        if (!success) {
            await this.logFailure(userId, event);
        }
    }
    
    private async getUserDetails(userId: string): Promise<User> {
        // ... fetch user
    }
    
    private formatMessage(event: UserEvent): string {
        return `Event: ${event.type} - ${event.description}`;
    }
    
    private async logFailure(userId: string, event: UserEvent): Promise<void> {
        // ... log for retry
    }
}
 
// ============================================
// USAGE: WIRING IT TOGETHER
// ============================================
// Create delegates and inject into delegator
 
// Production
const emailSender = new EmailNotificationSender(new RealEmailClient());
const notificationService = new NotificationService(emailSender);
 
// Or use SMS
const smsSender = new SMSNotificationSender(new TwilioGateway());
const smsNotificationService = new NotificationService(smsSender);
 
// Testing
const mockSender: NotificationSender = { send: jest.fn() };
const testService = new NotificationService(mockSender);

The Pattern at a Glance

Interface defines WHAT. Delegates define HOW (various implementations). Delegator uses WHICH (injected at construction). This separation is the heart of effective delegation.

Dependency Injection Patterns

Delegation and dependency injection (DI) are natural partners. DI provides the mechanism for supplying delegates to delegators. Let's examine the patterns:

Pattern 1: Constructor Injection (Preferred)

Provide all required delegates through the constructor:

class OrderService {
    constructor(
        private paymentProcessor: PaymentProcessor,
        private inventoryManager: InventoryManager,
        private notificationService: NotificationService
    ) {}
}

Advantages:

All dependencies visible at construction
Object is fully initialized immediately
Dependencies are immutable (can be readonly/final)
Easy to see what the class needs

Pattern 2: Property/Setter Injection

For optional dependencies or when runtime changes are needed:

class ReportGenerator {
    private formatter?: ReportFormatter;
    
    setFormatter(formatter: ReportFormatter): void {
        this.formatter = formatter;
    }
    
    generate(data: ReportData): Report {
        const formatter = this.formatter ?? new DefaultFormatter();
        return formatter.format(data);
    }
}

Use when:

Dependency is optional (has a default)
Dependency should be changeable after construction
Circular dependencies require it (rare, often a design smell)

Dependency Injection Pattern Comparison
Pattern	Use Case	Immutability	Testability
Constructor	Required dependencies	Supported (readonly)	Excellent
Setter	Optional dependencies	Not supported	Good
Method	Per-call variation	N/A (transient)	Excellent
Factory	Lazy/conditional creation	Depends	Good (inject factory)

Pattern 3: Method Injection

Pass the delegate as a parameter to specific methods:

class DataExporter {
    export(data: Data, formatter: DataFormatter): string {
        return formatter.format(data);
    }
}

// Different formatters for different calls
exporter.export(data, new JSONFormatter());
exporter.export(data, new CSVFormatter());

Use when:

Different delegates needed for different calls
Delegate is truly specific to one operation
No persistent delegate relationship needed

Pattern 4: Container/Framework Injection

Let a DI container wire dependencies:

// Definition (e.g., in a module)
@Injectable()
class OrderService {
    constructor(
        @Inject(PAYMENT_PROCESSOR) private paymentProcessor: PaymentProcessor,
        @Inject(INVENTORY_MANAGER) private inventoryManager: InventoryManager
    ) {}
}

// Registration
container.register(PAYMENT_PROCESSOR, StripePaymentProcessor);
container.register(INVENTORY_MANAGER, WarehouseInventoryManager);

// Resolution
const orderService = container.resolve(OrderService);

Advantages:

Centralized configuration
Lifecycle management
Easier to change implementations globally

DI Containers Are Optional

Composite Delegation Patterns

Sometimes you need to delegate to multiple objects of the same type, or chain delegates together. Here are patterns for complex delegation scenarios:

Pattern 1: Composite Delegate (Broadcast)

Delegate to multiple implementations, combining their results:

interface EventListener {
    onEvent(event: Event): void;
}

class CompositeEventListener implements EventListener {
    private listeners: EventListener[] = [];
    
    addListener(listener: EventListener): void {
        this.listeners.push(listener);
    }
    
    onEvent(event: Event): void {
        // Delegate to ALL listeners
        for (const listener of this.listeners) {
            listener.onEvent(event);
        }
    }
}

The composite itself implements the interface, so it can be used wherever a single delegate is expected. Clients don't know they're talking to a composite.

composite-delegation-patterns
TypeScript
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
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
// Pattern 2: Chain of Responsibility
// Delegate until one handler succeeds
 
interface RequestHandler {
    handle(request: Request): Response | null;
}
 
class HandlerChain implements RequestHandler {
    private handlers: RequestHandler[] = [];
    
    addHandler(handler: RequestHandler): void {
        this.handlers.push(handler);
    }
    
    handle(request: Request): Response | null {
        for (const handler of this.handlers) {
            const response = handler.handle(request);
            if (response !== null) {
                return response;  // First handler that responds wins
            }
        }
        return null;  // No handler could process
    }
}
 
// Concrete handlers
class AuthHandler implements RequestHandler {
    handle(request: Request): Response | null {
        if (request.path.startsWith('/auth')) {
            return this.processAuth(request);
        }
        return null;  // Pass to next handler
    }
}
 
class APIHandler implements RequestHandler {
    handle(request: Request): Response | null {
        if (request.path.startsWith('/api')) {
            return this.processAPI(request);
        }
        return null;
    }
}
 
// Usage
const chain = new HandlerChain();
chain.addHandler(new AuthHandler());
chain.addHandler(new APIHandler());
chain.addHandler(new StaticFileHandler());  // Fallback
 
const response = chain.handle(incomingRequest);
 
 
// Pattern 3: Decorator Chain
// Each delegate wraps the next, adding behavior
 
interface DataProcessor {
    process(data: string): string;
}
 
class BaseProcessor implements DataProcessor {
    process(data: string): string {
        return data;  // Identity—just return data
    }
}
 
class ValidationDecorator implements DataProcessor {
    constructor(private wrapped: DataProcessor) {}
    
    process(data: string): string {
        if (!data || data.length === 0) {
            throw new Error('Empty data');
        }
        return this.wrapped.process(data);
    }
}
 
class LoggingDecorator implements DataProcessor {
    constructor(private wrapped: DataProcessor) {}
    
    process(data: string): string {
        console.log('Processing:', data.substring(0, 50));
        const result = this.wrapped.process(data);
        console.log('Result:', result.substring(0, 50));
        return result;
    }
}
 
class CompressionDecorator implements DataProcessor {
    constructor(private wrapped: DataProcessor) {}
    
    process(data: string): string {
        const processed = this.wrapped.process(data);
        return compress(processed);
    }
}
 
// Build a chain of decorators
const processor: DataProcessor = 
    new LoggingDecorator(
        new ValidationDecorator(
            new CompressionDecorator(
                new BaseProcessor()
            )
        )
    );
 
// Each layer delegates to the next while adding its behavior
const result = processor.process(inputData);

Pattern 3: Strategy Selection

Choose among delegates based on context:

class PaymentProcessor {
    private strategies: Map<PaymentMethod, PaymentStrategy> = new Map();
    
    registerStrategy(method: PaymentMethod, strategy: PaymentStrategy): void {
        this.strategies.set(method, strategy);
    }
    
    process(payment: Payment): Result {
        const strategy = this.strategies.get(payment.method);
        if (!strategy) {
            throw new Error(`No strategy for ${payment.method}`);
        }
        return strategy.process(payment);  // Delegate to selected strategy
    }
}

// Register strategies
processor.registerStrategy(PaymentMethod.CARD, new CardStrategy());
processor.registerStrategy(PaymentMethod.BANK, new BankTransferStrategy());
processor.registerStrategy(PaymentMethod.CRYPTO, new CryptoStrategy());

Composition of Composition

The Null Object Pattern

The Problem:

class Logger {
    private formatter?: Formatter;
    
    log(message: string): void {
        // Null check everywhere!
        const formatted = this.formatter 
            ? this.formatter.format(message) 
            : message;
        console.log(formatted);
    }
}

The Solution: Null Object

interface Formatter {
    format(message: string): string;
}

// Null Object—does nothing, returns input unchanged
class NullFormatter implements Formatter {
    format(message: string): string {
        return message;  // Identity—no formatting
    }
}

class Logger {
    private formatter: Formatter;  // Never null!
    
    constructor(formatter: Formatter = new NullFormatter()) {
        this.formatter = formatter;
    }
    
    log(message: string): void {
        // No null check needed—delegation just works
        const formatted = this.formatter.format(message);
        console.log(formatted);
    }
}

null-object-examples
TypeScript
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
65
66
67
// More Null Object Examples
 
// Null Logger—silently ignores all log calls
interface Logger {
    log(level: LogLevel, message: string): void;
    error(message: string, error?: Error): void;
}
 
class NullLogger implements Logger {
    log(level: LogLevel, message: string): void {
        // Do nothing
    }
    
    error(message: string, error?: Error): void {
        // Do nothing
    }
}
 
// Use when logging should be disabled
const silentService = new DataService(new NullLogger());
 
 
// Null Cache—always misses, never stores
interface Cache<T> {
    get(key: string): T | undefined;
    set(key: string, value: T): void;
}
 
class NullCache<T> implements Cache<T> {
    get(key: string): T | undefined {
        return undefined;  // Always cache miss
    }
    
    set(key: string, value: T): void {
        // Do nothing—don't store
    }
}
 
// Use when caching should be disabled
const uncachedService = new UserService(new NullCache<User>());
 
 
// Null Validator—always passes
interface Validator<T> {
    validate(value: T): ValidationResult;
}
 
class NullValidator<T> implements Validator<T> {
    validate(value: T): ValidationResult {
        return { valid: true, errors: [] };  // Always valid
    }
}
 
// Use when validation should be skipped
const trustingService = new FormHandler(new NullValidator<FormData>());
 
 
// Null Event Publisher—events disappear
interface EventPublisher {
    publish(event: Event): Promise<void>;
}
 
class NullEventPublisher implements EventPublisher {
    async publish(event: Event): Promise<void> {
        // Event is silently dropped
    }
}

Benefits of Null Object Pattern

•Eliminates null checks — No more if (delegate !== null) scattered through code.
•Uniform delegation — Every path goes through delegation; no special cases.
•Simplifies client code — Clients don't need to know if the delegate is "real" or null.
•Enables opt-out behavior — Provides a way to disable features without conditionals.
•Testing helper — Use null objects when you don't care about a particular delegate's behavior.

Singleton Null Objects

Since null objects are stateless, you can make them singletons to avoid creating redundant instances. Export a shared instance: export const NULL_LOGGER = new NullLogger();

Common Implementation Mistakes

Even with good intentions, delegation can be implemented poorly. Here are common mistakes and how to avoid them:

Mistake 1: Internal Instantiation of Delegates

// BAD: Tight coupling, untestable
class OrderService {
    private paymentGateway = new StripePaymentGateway();  // Hardcoded!
}

// GOOD: Injected dependency
class OrderService {
    constructor(private paymentGateway: PaymentGateway) {}  // Interface
}

Why it's bad: You can't substitute different implementations, can't mock for testing, and are tightly coupled to a specific concrete class.

Mistake 2: Depending on Concrete Classes Instead of Interfaces

// BAD: Depends on concrete class
class ReportGenerator {
    constructor(private formatter: PDFFormatter) {}  // Concrete!
}

// GOOD: Depends on interface
class ReportGenerator {
    constructor(private formatter: ReportFormatter) {}  // Interface
}

Why it's bad: Defeats the purpose of delegation—you're still coupled to a specific implementation.

Delegation Anti-Patterns to Avoid

•Internal instantiation — Always inject delegates; never new ConcreteDelegate() inside the delegator.
•Concrete dependencies — Depend on interfaces, not concrete classes.
•Leaky abstractions — Don't let delegate implementation details leak into the delegator.
•Fat interfaces — Keep delegate interfaces focused; avoid kitchen-sink interfaces.
•Null checks everywhere — Use Null Object pattern instead of checking if (delegate !== null).
•Exposing delegate directly — Don't return your internal delegate; it breaks encapsulation.
•Optional injection without defaults — If a delegate is optional, provide a Null Object default.

Mistake 3: Leaking Delegate Implementation Details

// BAD: Exposes how delegate works internally
class DocumentService {
    getDocument(id: string): Document {
        const rawData = this.storage.getRawBytes(id);  // Storage detail
        const checksum = this.storage.getChecksum(id);  // Storage detail
        // ... process using storage internals
    }
}

// GOOD: Uses delegate at the right abstraction level
class DocumentService {
    getDocument(id: string): Document {
        return this.storage.retrieveDocument(id);  // Appropriate abstraction
    }
}

Mistake 4: Exposing Internal Delegates

// BAD: Breaks encapsulation
class Car {
    getEngine(): Engine {
        return this.engine;  // Exposes internal!
    }
}

// Caller can now: car.getEngine().overheat();  // Bypasses Car!

// GOOD: Expose capabilities, not internals
class Car {
    startEngine(): void {
        this.engine.start();
    }
    
    getEngineStatus(): EngineStatus {
        return this.engine.getStatus();  // Read-only info, not the engine itself
    }
}

The "Getter" Smell

Code Organization for Delegation

How you organize delegation-heavy code affects maintainability. Here are proven organizational patterns:

Pattern 1: Interfaces Near Consumers

Place interfaces close to where they're used (in the consumer's module), not with implementations:

src/
  orders/
    OrderService.ts       # Delegator
    PaymentGateway.ts     # Interface (defined here, used here)
  payments/
    StripeGateway.ts      # Implementation of PaymentGateway
    PayPalGateway.ts      # Another implementation

Why: The interface is part of the Order module's contract. Payment implementations depend on the interface, not the other way around. This follows the Dependency Inversion Principle.

Pattern 2: Separate Interface Packages

For shared interfaces used across multiple modules:

src/
  interfaces/
    PaymentGateway.ts
    NotificationSender.ts
  orders/
    OrderService.ts
  payments/
    StripeGateway.ts
  notifications/
    EmailSender.ts

module-organization
TypeScript
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
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
// Pattern 3: Feature-Based Organization
// Group by feature, with clear internal structure
 
// src/orders/
// ├── index.ts                  # Public exports
// ├── OrderService.ts           # Main service (delegator)
// ├── types.ts                  # Interfaces this module defines
// │   └── PaymentProcessor.ts   # Interface for payment delegation
// │   └── InventoryChecker.ts   # Interface for inventory delegation
// └── testing/
//     └── mocks.ts              # Mock implementations for testing
 
// src/orders/types.ts
export interface PaymentProcessor {
    process(amount: Money): Promise<PaymentResult>;
}
 
export interface InventoryChecker {
    check(items: OrderItem[]): Promise<InventoryStatus>;
}
 
// src/orders/OrderService.ts
import { PaymentProcessor, InventoryChecker } from './types';
 
export class OrderService {
    constructor(
        private paymentProcessor: PaymentProcessor,
        private inventoryChecker: InventoryChecker
    ) {}
    
    // ... implementation
}
 
// src/orders/testing/mocks.ts
import { PaymentProcessor, InventoryChecker } from '../types';
 
export class MockPaymentProcessor implements PaymentProcessor {
    public lastAmount?: Money;
    
    async process(amount: Money): Promise<PaymentResult> {
        this.lastAmount = amount;
        return { success: true };
    }
}
 
// src/orders/index.ts
export { OrderService } from './OrderService';
export type { PaymentProcessor, InventoryChecker } from './types';
// Don't export mocks from main index—separate test imports
 
 
// Pattern 4: Composition Root
// Central place where all delegation wiring happens
 
// src/composition-root.ts
import { OrderService } from './orders';
import { StripePaymentProcessor } from './payments/stripe';
import { WarehouseInventoryChecker } from './inventory/warehouse';
import { EmailNotificationSender } from './notifications/email';
 
export function createOrderService(): OrderService {
    return new OrderService(
        new StripePaymentProcessor(config.stripe),
        new WarehouseInventoryChecker(config.warehouse)
    );
}
 
export function createNotificationService(): NotificationService {
    return new NotificationService(
        new EmailNotificationSender(config.email)
    );
}
 
// Entry point uses composition root
// src/main.ts
import { createOrderService, createNotificationService } from './composition-root';
 
const orderService = createOrderService();
const notificationService = createNotificationService();

Pattern 4: Composition Root

Have a single location (the "composition root") where all delegation wiring happens:

Entry point or startup code creates all objects
Dependencies are wired together in one place
No new ConcreteDelegate() scattered throughout codebase
Easy to see and modify the overall wiring

This pattern is especially valuable in larger applications and aligns well with DI containers.

Keep Interfaces Stable

Delegation Implementation Checklist

Use this checklist when implementing delegation to ensure you're following best practices:

Before Implementation:

Pre-Implementation Checklist

•☐ Identified the varying behavior — What specifically will be delegated?
•☐ Defined a focused interface — Does it have a single responsibility?
•☐ Named the interface appropriately — Does the name describe the role/capability?
•☐ Considered multiple implementations — Are there at least two conceivable implementations?
•☐ Checked for existing interfaces — Can you reuse an existing interface?

Implementation Checklist

•☐ Delegate via interface — Delegator depends on interface, not concrete class
•☐ Inject via constructor — Required delegates injected at construction
•☐ Immutable reference — Delegate reference is readonly/final when appropriate
•☐ No internal instantiation — Never new ConcreteDelegate() in the delegator
•☐ Null object for optional — Use Null Object pattern if delegate is optional
•☐ Clear forwarding — Delegation calls are obvious and intentional
•☐ Appropriate abstraction level — Interface matches delegator's abstraction level

Post-Implementation Checklist

•☐ Testable — Can you test the delegator with a mock delegate?
•☐ Documented — Is the interface contract clear (parameters, return values, errors)?
•☐ Encapsulated — Delegate's internals hidden; no leaky abstractions?
•☐ Swappable — Can you easily switch to a different implementation?
•☐ Organized — Are interfaces and implementations in sensible locations?
•☐ Wired correctly — Is composition root or DI container configured properly?

Review Before PR

Before submitting code with new delegation, walk through this checklist. Catching issues before code review saves everyone time and results in better designs reaching production.

Summary: Implementing Delegation

We've covered comprehensive guidance for implementing delegation effectively. Let's consolidate the key insights:

Key Takeaways

•Standard structure — Interface defines contract; delegates implement; delegator uses via injection.
•Dependency injection — Prefer constructor injection; use setters for optional delegates; consider DI containers for larger systems.
•Composite patterns — Use Composite for broadcast, Chain of Responsibility for sequential handling, Decorator for layered behavior.
•Null Object pattern — Eliminate null checks by providing a do-nothing implementation.
•Avoid common mistakes — No internal instantiation, depend on interfaces, don't leak abstractions, don't expose delegates.
•Code organization — Interfaces near consumers, composition root for wiring, feature-based module structure.
•Use the checklist — Systematic verification catches issues before they reach production.

Module Complete

With this page, we've completed our exploration of the Delegation Pattern. You now understand:

What delegation is and why it matters
How to forward requests to contained objects effectively
When to choose delegation over inheritance
How to implement delegation with production-quality code

In the Next Module:

Module Complete