We've now explored both inheritance (in earlier chapters) and delegation (in this module). Both mechanisms allow objects to reuse behavior—to leverage existing implementations rather than writing everything from scratch. But they achieve this goal in fundamentally different ways, with profound implications for design flexibility, maintainability, and system evolution.

Inheritance says: "I am a specialized version of you. I inherit your behavior and override what I need to."

Delegation says: "I use your capabilities. I forward requests to you and compose your behavior with mine."

This page directly compares these two approaches, examining their fundamental differences, tradeoffs, and appropriate use cases. By the end, you'll have a clear framework for choosing between them.

Let's establish the core conceptual differences between delegation and inheritance. These aren't just implementation details—they reflect fundamentally different approaches to structuring object relationships.

Type Relationship vs Object Relationship

• Inheritance creates a type relationship. A subclass IS a subtype of its parent. When you create Dog extends Animal, every Dog instance IS an Animal.

• Delegation creates an object relationship. A delegator HAS a delegate. When you create Car with a Engine, the Car instance HAS an Engine instance, but is not an Engine.

Static vs Dynamic

• Inheritance is static. The parent class is fixed at compile time. A Dog is forever an Animal; this cannot change at runtime.

• Delegation can be dynamic. The delegate can be swapped at runtime. A Car can have its Engine replaced while the program executes.

Visibility

• Inheritance provides visibility into parent internals. Subclasses can access protected members and override methods.

• Delegation respects encapsulation. Delegators only see the delegate's public interface—no access to internals.

Implicit vs Explicit Behavior

• Inheritance makes behavior acquisition implicit. A subclass automatically has all parent methods. You don't see in the subclass code what methods are available—they come from the hierarchy.

• Delegation makes behavior acquisition explicit. Every delegated method must be explicitly forwarded. You can see in the delegator's code exactly what capabilities it provides.

Change Propagation

• Inheritance propagates parent changes to all descendants. If the parent changes, all subclasses are affected—for better or worse.

• Delegation isolates changes behind interfaces. A delegate's internal changes don't affect delegators as long as the interface contract is maintained.

Delegation provides several forms of flexibility that inheritance cannot match:

1. Runtime Behavior Changes

With delegation, behavior can be changed while the program is running:

class Duck {
    constructor(private flyBehavior: FlyBehavior) {}
    
    fly(): void {
        this.flyBehavior.fly();
    }
    
    setFlyBehavior(behavior: FlyBehavior): void {
        this.flyBehavior = behavior;
    }
}

// Runtime change!
const duck = new Duck(new StandardFlight());
duck.fly();  // Uses StandardFlight

duck.setFlyBehavior(new RocketPoweredFlight());
duck.fly();  // Now uses RocketPoweredFlight!

With inheritance, you'd need to create a new RocketPoweredDuck subclass and recreate the object—losing all state in the process.

2. Mixing Behaviors from Multiple Sources

Delegation allows composing behaviors from multiple, unrelated sources:

With inheritance, you'd need a complex hierarchy trying to represent all combinations (FlyingSwimmingAnimal, SwimmingWalkingAnimal, etc.), quickly leading to a combinatorial explosion.

3. Selective Implementation

Delegation lets you choose exactly what to expose:

class LimitedList<T> {
    private items: T[] = [];
    
    // Expose only what we want
    add(item: T): void { this.items.push(item); }
    get(index: number): T { return this.items[index]; }
    
    // Intentionally NOT exposing: splice, shift, unshift, etc.
}

With inheritance, you inherit everything—even things you'd rather hide.

4. Independent Evolution

Delegates can evolve independently of delegators:

// Version 2 of formatter—internal changes only
class MarkdownFormatterV2 implements Formatter {
    // Completely rewritten internals
    // Interface unchanged—no delegator impact
}

We've discussed inheritance's problems in earlier chapters, but it's instructive to revisit them in direct comparison with delegation:

The Fragile Base Class Problem

Changes to a base class can break subclasses in unexpected ways, even when the public interface hasn't changed:

// Base class
class Collection {
    add(item: Item): void {
        this.items.push(item);
    }
    
    addAll(items: Item[]): void {
        items.forEach(item => this.add(item));  // Calls add()
    }
}

// Subclass
class CountingCollection extends Collection {
    private count = 0;
    
    add(item: Item): void {
        this.count++;
        super.add(item);
    }
}

// Problem: addAll calls add, so count is incremented per item
// If base class changes addAll to not use add, behavior breaks!

Delegation avoids this because the delegator doesn't depend on how the delegate implements things internally—only on the interface contract.

The "Broken" Liskov Substitution Problem

Inheritance encourages creating subclasses that don't truly substitute for their parents:

class Rectangle {
    setWidth(w: number): void { this.width = w; }
    setHeight(h: number): void { this.height = h; }
}

class Square extends Rectangle {
    // Must override to maintain invariant
    setWidth(w: number): void {
        this.width = w;
        this.height = w;  // Breaks Rectangle's contract!
    }
}

Delegation doesn't create these traps because there's no subtype relationship to violate:

class Square {
    private rectangle: Rectangle;
    
    setSide(s: number): void {
        this.rectangle.setWidth(s);
        this.rectangle.setHeight(s);
    }
    // No pretense of being a Rectangle—no LSP concerns
}

Despite delegation's advantages, inheritance remains the right choice in specific situations. Understanding these helps avoid dogmatic rejection of a useful tool.

1. True Is-A Relationships with Full Substitutability

When Liskov Substitution genuinely holds—when every subclass instance can substitute for the parent in all contexts without breaking assumptions—inheritance models the domain correctly:

// Genuine is-a: Every IOException IS-A Exception
class IOException extends Exception { }

// Genuine is-a: Every HttpServletRequest IS-A ServletRequest
class HttpServletRequest extends ServletRequest { }

2. Framework Extension Points Designed for Inheritance

Some frameworks are designed around inheritance, providing base classes with protected methods as extension hooks (Template Method pattern):

// Framework provides
abstract class TestCase {
    protected setUp(): void { }  // Override hook
    protected tearDown(): void { }  // Override hook
    abstract runTest(): void;
}

// You extend
class MyTest extends TestCase {
    protected setUp(): void {
        this.db = createTestDatabase();
    }
}

Fighting the framework's design rarely ends well. Accept inheritance where it's idiomatically expected.

3. Immutable Value Types

Inheritance works well for immutable values because there's no mutable state to corrupt and no behavior that needs runtime variation:

// Value types—immutable, no behavior to swap
class Money {
    constructor(readonly amount: number, readonly currency: string) {}
}

class USDMoney extends Money {
    constructor(amount: number) {
        super(amount, 'USD');
    }
}

4. Language/Platform Requirements

Some patterns require inheritance due to language mechanics:

• Implementing abstract classes that require shared state
• Platform APIs that expect specific base classes
• Serialization mechanisms that traverse hierarchies

5. Small, Closed, Stable Hierarchies

When you control all subclasses, the hierarchy is small, and requirements are stable, inheritance's downsides are mitigated:

// Closed enumeration—all subclasses known and controlled
abstract class HttpMethod {
    abstract readonly name: string;
}
class GET extends HttpMethod { readonly name = 'GET'; }
class POST extends HttpMethod { readonly name = 'POST'; }
// ...all methods known upfront

Let's examine the same problem solved both ways. This concrete comparison illuminates the practical differences.

The Problem: We need various types of loggers—file logger, database logger, console logger—that share some common functionality but differ in their output destination.

Given everything we've discussed, here's a practical framework for choosing between delegation and inheritance:

Step 1: Ask "Is there a true IS-A relationship with behavioral substitutability?"

Not "could this be modeled as IS-A," but "IS this genuinely a subtype that can substitute in all contexts?"

• If yes and you're confident, consider inheritance
• If unsure, favor delegation

Step 2: Ask "Might the behavior need to vary at runtime?"

If there's any chance you'll need different behavior without recreating objects, delegation is required.

Step 3: Ask "Is this a framework extension point designed for inheritance?"

If yes, follow the framework's idiom—inheritance is expected.

Step 4: Ask "Will there be multiple independent dimensions of variation?"

If you need to combine behaviors from multiple orthogonal sources, delegation is essential. Inheritance creates exponential hierarchies for combinations.

The Heuristic Summary

Default to delegation. Use inheritance when:

1. There's a genuine, stable IS-A relationship
2. You're extending a framework designed for inheritance
3. You're working with immutable value types in a small hierarchy
4. The cost of delegation's verbosity outweighs flexibility needs in a trivial case

In all other cases, delegation provides more flexibility with fewer risks.

The Cost Consideration

Delegation has some costs:

• More explicit wiring (constructor injection)
• More interfaces to define
• Slightly more verbose code

But these costs are typically minor compared to the benefits. The explicitness is often a feature, not a bug—dependencies are visible and testable.

Inheritance costs:

• Future inflexibility
• Fragile base class risks
• Testing difficulty
• Hidden coupling

These costs compound over time as systems evolve.

Inheritance and delegation aren't mutually exclusive. Many real-world designs use both strategically:

Pattern 1: Inherit Structure, Delegate Behavior

Use inheritance for a stable type hierarchy, but delegate specific behaviors:

// Inherit for type relationship
abstract class Shape {
    abstract getArea(): number;
    
    // Delegate rendering behavior
    constructor(protected renderer: ShapeRenderer) {}
    
    render(): void {
        this.renderer.render(this);
    }
}

class Circle extends Shape {
    constructor(public radius: number, renderer: ShapeRenderer) {
        super(renderer);
    }
    
    getArea(): number {
        return Math.PI * this.radius * this.radius;
    }
}

// Different renderers for same shapes
const circle1 = new Circle(5, new SVGRenderer());
const circle2 = new Circle(5, new CanvasRenderer());

The type hierarchy (Shape → Circle) is stable and represents genuine IS-A. The varying behavior (rendering) is delegated.

Pattern 2: Abstract Class for Shared Code, Interface for Contract

Define the contract as an interface, provide an optional abstract base for shared implementation:

interface Repository<T> {
    find(id: string): T | null;
    save(entity: T): void;
}

abstract class AbstractRepository<T> implements Repository<T> {
    // Shared logic that many repositories need
    protected cache = new Map<string, T>();
    
    find(id: string): T | null {
        if (this.cache.has(id)) return this.cache.get(id)!;
        const entity = this.doFind(id);
        if (entity) this.cache.set(id, entity);
        return entity;
    }
    
    protected abstract doFind(id: string): T | null;
    // ...
}

// Option 1: Inherit shared logic
class SQLUserRepository extends AbstractRepository<User> {
    protected doFind(id: string): User | null { ... }
}

// Option 2: Implement from scratch
class InMemoryUserRepository implements Repository<User> {
    private data = new Map<string, User>();
    find(id: string): User | null { return this.data.get(id) ?? null; }
    save(user: User): void { this.data.set(user.id, user); }
}

Using an interface as the contract allows pure delegation while optionally offering inheritance for implementations that want shared logic.

We've comprehensively compared delegation and inheritance. Let's consolidate the key insights:

What's Next:

Now that we've compared delegation with inheritance, the final page focuses on Implementing Delegation Effectively—practical patterns, code organization, and best practices for using delegation in production codebases.