System Design (LLD)Polymorphism Through Interfaces

Polymorphism Through Interfaces

LevelIntermediate

Duration60 mins

TopicPolymorphism Through Interfaces

2 / 4

Implementing Multiple Interfaces

Beyond Single Inheritance

In the previous page, we established that interfaces are behavioral contracts—promises about what an object can do. Now we encounter one of the most liberating features of interfaces: a single class can implement multiple interfaces simultaneously.

This is profoundly different from class inheritance. Most languages restrict class inheritance to a single parent (to avoid the infamous "diamond problem"), but interface implementation has no such restriction. An object can sign as many behavioral contracts as it needs.

Think of it this way: a person can simultaneously be a driver (can drive vehicles), a swimmer (can swim), a cook (can prepare food), and a musician (can play instruments). These aren't conflicting identities—they're different capabilities the same entity possesses. In OOP terms, a class can implement Driver, Swimmer, Cook, and Musician interfaces all at once.

What You Will Learn

By the end of this page, you will understand how to implement multiple interfaces in a single class, why this capability is fundamental to flexible design, the composition patterns it enables, and the differences between multiple interface implementation and multiple inheritance.

The Syntax of Multiple Implementation

Implementing multiple interfaces is syntactically straightforward. A class simply lists all the interfaces it promises to fulfill, then provides implementations for every method from every interface.

multiple-interface-syntax.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
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
// Define separate, focused interfaces
interface Printable {
    print(): string;
    getFormat(): string;
}
 
interface Saveable {
    save(path: string): Promise<void>;
    getLastSaved(): Date | null;
}
 
interface Shareable {
    share(recipient: string): Promise<boolean>;
    getShareLink(): string;
}
 
interface Exportable {
    export(format: 'pdf' | 'docx' | 'html'): Promise<Blob>;
    getSupportedFormats(): string[];
}
 
// A Document class implements ALL of these interfaces
class Document implements Printable, Saveable, Shareable, Exportable {
    private content: string;
    private lastSavedAt: Date | null = null;
    private id: string;
    
    constructor(content: string) {
        this.content = content;
        this.id = crypto.randomUUID();
    }
    
    // === Printable implementation ===
    print(): string {
        return this.content;
    }
    
    getFormat(): string {
        return 'plain-text';
    }
    
    // === Saveable implementation ===
    async save(path: string): Promise<void> {
        // Actual save logic here
        console.log(`Saving to ${path}`);
        this.lastSavedAt = new Date();
    }
    
    getLastSaved(): Date | null {
        return this.lastSavedAt;
    }
    
    // === Shareable implementation ===
    async share(recipient: string): Promise<boolean> {
        console.log(`Sharing with ${recipient}`);
        return true;
    }
    
    getShareLink(): string {
        return `https://docs.app/share/${this.id}`;
    }
    
    // === Exportable implementation ===
    async export(format: 'pdf' | 'docx' | 'html'): Promise<Blob> {
        console.log(`Exporting as ${format}`);
        return new Blob([this.content], { type: 'text/plain' });
    }
    
    getSupportedFormats(): string[] {
        return ['pdf', 'docx', 'html'];
    }
}
 
// The Document can now be used polymorphically through ANY of its interfaces
const doc = new Document("Hello, World!");
 
// As Printable
function printDocument(printable: Printable): void {
    console.log(printable.print());
}
 
// As Saveable
function autoSave(saveable: Saveable): void {
    saveable.save('/auto-save');
}
 
// As Shareable
function shareWithTeam(shareable: Shareable): void {
    shareable.share('team@company.com');
}
 
// As Exportable
function exportToPdf(exportable: Exportable): void {
    exportable.export('pdf');
}
 
// All work with the same Document instance!
printDocument(doc);
autoSave(doc);
shareWithTeam(doc);
exportToPdf(doc);

The key insight: The same Document object can be viewed through multiple lenses. When passed to printDocument(), it's treated as a Printable. When passed to autoSave(), it's treated as a Saveable. The object has a single implementation but multiple interfaces through which it can be accessed.

This is fundamentally different from inheritance. The Document doesn't inherit from Printable—it isn't a specialized version of Printable. Instead, it fulfills the contract that Printable defines. It's a subtle but crucial distinction.

Why Multiple Interfaces Matter

Multiple interface implementation isn't just a syntactic convenience—it fundamentally changes how we design systems. It enables several powerful capabilities:

Powers of Multiple Interface Implementation

•Role-Based Access — Different parts of your system can see only the interface they need. The printing subsystem sees Printable objects; it doesn't need to know about Shareable capabilities.
•Composition Over Inheritance — Instead of complex inheritance hierarchies, you compose capabilities through interfaces. Need something that prints AND shares? Accept Printable & Shareable.
•Interface Segregation Made Easy — Each interface can be minimal and focused. Classes compose them as needed rather than implementing one large interface.
•Flexible Evolution — Add new capabilities by implementing additional interfaces. Existing code using the old interfaces continues to work.
•Test Isolation — Tests can mock exactly the interface being tested. Testing print functionality doesn't require mocking save/share/export.
•Documentation Through Types — The interfaces a class implements document its capabilities. implements Printable, Saveable, Shareable is self-documenting.

Think in Capabilities, Not Categories

Multiple interfaces encourage thinking about objects in terms of what they can DO rather than what they ARE. A Document isn't in a category—it has capabilities. This shift from categorical to capability-based thinking leads to more flexible, composable designs.

role-based-access.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
65
66
67
68
69
70
// Different subsystems see different views of the same objects
 
interface Printable {
    print(): string;
}
 
interface Shareable {
    share(recipient: string): Promise<void>;
}
 
interface Deletable {
    delete(): Promise<void>;
}
 
// The Printing subsystem only knows about Printable
class PrintQueue {
    private queue: Printable[] = [];
    
    addToQueue(item: Printable): void {
        // Only sees print capability - doesn't know about share/delete
        this.queue.push(item);
    }
    
    processQueue(): void {
        this.queue.forEach(item => console.log(item.print()));
    }
}
 
// The Sharing subsystem only knows about Shareable  
class SharingService {
    async shareWithAll(items: Shareable[], recipients: string[]): Promise<void> {
        // Only sees share capability - doesn't know about print/delete
        for (const item of items) {
            for (const recipient of recipients) {
                await item.share(recipient);
            }
        }
    }
}
 
// The Cleanup subsystem only knows about Deletable
class CleanupService {
    async cleanup(items: Deletable[]): Promise<void> {
        // Only sees delete capability - doesn't know about print/share
        for (const item of items) {
            await item.delete();
        }
    }
}
 
// A Document implementing all three can be used by all subsystems
class Document implements Printable, Shareable, Deletable {
    constructor(private content: string) {}
    
    print(): string { return this.content; }
    async share(recipient: string): Promise<void> { /* ... */ }
    async delete(): Promise<void> { /* ... */ }
}
 
// Same document, different perspectives
const doc = new Document("Report Q4");
 
const printQueue = new PrintQueue();
const sharingService = new SharingService();
const cleanupService = new CleanupService();
 
// Each service only sees what it needs
printQueue.addToQueue(doc);        // Sees Printable
sharingService.shareWithAll([doc], ["team@co.com"]);  // Sees Shareable
cleanupService.cleanup([doc]);     // Sees Deletable

Intersection Types: Requiring Multiple Interfaces

Sometimes you need to accept objects that implement multiple specific interfaces. TypeScript provides intersection types for this purpose using the & operator. This lets you specify exactly which combination of capabilities you require.

intersection-types.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
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
interface Identifiable {
    getId(): string;
    getName(): string;
}
 
interface Timestamped {
    getCreatedAt(): Date;
    getUpdatedAt(): Date;
}
 
interface Auditable {
    getLastModifiedBy(): string;
    getChangeHistory(): ChangeEntry[];
}
 
interface Versionable {
    getVersion(): number;
    getPreviousVersions(): string[];
}
 
// Using intersection types to require MULTIPLE interfaces
// This function needs objects that are:
// - Identifiable (has ID and name)
// - Timestamped (has creation/update times)
// - Auditable (tracks who changed what)
function generateAuditReport(
    entity: Identifiable & Timestamped & Auditable
): AuditReport {
    return {
        entityId: entity.getId(),
        entityName: entity.getName(),
        createdAt: entity.getCreatedAt(),
        updatedAt: entity.getUpdatedAt(),
        lastModifiedBy: entity.getLastModifiedBy(),
        history: entity.getChangeHistory()
    };
}
 
// This backup function requires Identifiable + Versionable
function backupEntity(
    entity: Identifiable & Versionable
): void {
    console.log(`Backing up ${entity.getName()} v${entity.getVersion()}`);
    // Store current and previous versions
}
 
// A class implementing all four can be used with any combination
class CriticalDocument implements Identifiable, Timestamped, Auditable, Versionable {
    private id: string;
    private name: string;
    private createdAt: Date;
    private updatedAt: Date;
    private modifiedBy: string;
    private history: ChangeEntry[] = [];
    private version: number = 1;
    private previousVersions: string[] = [];
    
    constructor(name: string, createdBy: string) {
        this.id = crypto.randomUUID();
        this.name = name;
        this.createdAt = new Date();
        this.updatedAt = new Date();
        this.modifiedBy = createdBy;
    }
    
    // Identifiable
    getId(): string { return this.id; }
    getName(): string { return this.name; }
    
    // Timestamped
    getCreatedAt(): Date { return this.createdAt; }
    getUpdatedAt(): Date { return this.updatedAt; }
    
    // Auditable
    getLastModifiedBy(): string { return this.modifiedBy; }
    getChangeHistory(): ChangeEntry[] { return [...this.history]; }
    
    // Versionable
    getVersion(): number { return this.version; }
    getPreviousVersions(): string[] { return [...this.previousVersions]; }
}
 
// CriticalDocument satisfies both function requirements
const doc = new CriticalDocument("Financial Report", "alice@company.com");
 
generateAuditReport(doc);  // ✅ Works - doc is Identifiable & Timestamped & Auditable
backupEntity(doc);         // ✅ Works - doc is Identifiable & Versionable
 
// A simpler class implementing only some interfaces
class SimpleNote implements Identifiable, Timestamped {
    constructor(
        private id: string,
        private name: string,
        private createdAt: Date,
        private updatedAt: Date
    ) {}
    
    getId(): string { return this.id; }
    getName(): string { return this.name; }
    getCreatedAt(): Date { return this.createdAt; }
    getUpdatedAt(): Date { return this.updatedAt; }
}
 
const note = new SimpleNote("id-123", "Quick Note", new Date(), new Date());
 
// generateAuditReport(note);  // ❌ Error! SimpleNote is not Auditable
// backupEntity(note);         // ❌ Error! SimpleNote is not Versionable

Intersection Types Create Precision

Intersection types let you express precisely what combination of capabilities you need. Rather than creating a new interface that combines all the methods (which would require a new type for every combination), you compose existing interfaces on demand. This keeps your interface definitions clean and focused.

Multiple Interfaces vs Multiple Inheritance

Many languages restrict class inheritance to a single parent to avoid the "diamond problem." But they allow multiple interface implementation without restriction. Why the difference?

The answer lies in what each provides:

Classes provide implementation — They contain actual code that runs. With multiple inheritance, if two parent classes implement the same method differently, the child faces an irresolvable conflict: which implementation should it use?

Interfaces provide only contracts — They declare what methods must exist but contain no implementation. There's no conflict because there's no code to conflict with.

Multiple Inheritance vs Multiple Interfaces
Aspect	Multiple Class Inheritance	Multiple Interface Implementation
Provides	Implementation (code)	Contract (method signatures only)
Diamond Problem	Yes - conflicting implementations	No - no implementations to conflict
State Inheritance	Inherits parent state (fields)	No state inheritance
Allowed in Most Languages	No (Java, C#, TypeScript)	Yes
Cognitive Complexity	High - must understand all parent implementations	Lower - just implement declared methods
Fragile Base Class Problem	Yes - parent changes affect children	Minimal - only contract changes affect implementers

diamond-problem-avoided.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
// The Diamond Problem with Multiple Inheritance (hypothetical)
// If TypeScript allowed multiple class inheritance:
 
class Scannable {
    scan(): Image {
        console.log("Scanning using default scanner...");
        return new Image();
    }
}
 
class Faxable {
    scan(): Image {  // Same method name, different implementation!
        console.log("Scanning for fax transmission...");
        return new Image();
    }
}
 
// ❌ PROBLEM: If MultiFunctionDevice extended both,
// which scan() implementation would it inherit?
// class MultiFunctionDevice extends Scannable, Faxable { }
 
// With interfaces, there's no ambiguity:
 
interface IScanner {
    scan(): Image;
}
 
interface IFax {
    scan(): Image;  // Same signature - no problem!
    send(number: string, image: Image): void;
}
 
// The CLASS decides the implementation - there's only ONE
class MultiFunctionDevice implements IScanner, IFax {
    scan(): Image {
        // We provide THE implementation - no inheritance conflict
        console.log("Scanning via multi-function device...");
        return new Image();
    }
    
    send(number: string, image: Image): void {
        console.log(`Faxing to ${number}...`);
    }
}
 
// Both interface contracts are satisfied by the SAME method implementation
// No ambiguity, no diamond problem

Method Signature Conflicts

While interfaces avoid the diamond problem, you can still encounter issues if two interfaces declare methods with the same name but DIFFERENT signatures. For instance, if one interface declares process(): void and another declares process(): Result, implementing both creates a conflict. Design interfaces carefully to avoid such naming collisions.

The Mixin Pattern with Interfaces

A powerful pattern enabled by multiple interfaces is the mixin pattern. Mixins provide reusable functionality that can be "mixed into" classes. When combined with interfaces, mixins offer a way to share implementation while maintaining type safety.

mixin-pattern.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
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
// Define interfaces for each capability
interface Timestampable {
    createdAt: Date;
    updatedAt: Date;
    touch(): void;
}
 
interface SoftDeletable {
    deletedAt: Date | null;
    isDeleted(): boolean;
    softDelete(): void;
    restore(): void;
}
 
// Type for a class constructor
type Constructor<T = {}> = new (...args: any[]) => T;
 
// Mixin functions that add implementation to any base class
function Timestampable<TBase extends Constructor>(Base: TBase) {
    return class extends Base implements Timestampable {
        createdAt = new Date();
        updatedAt = new Date();
        
        touch(): void {
            this.updatedAt = new Date();
        }
    };
}
 
function SoftDeletable<TBase extends Constructor>(Base: TBase) {
    return class extends Base implements SoftDeletable {
        deletedAt: Date | null = null;
        
        isDeleted(): boolean {
            return this.deletedAt !== null;
        }
        
        softDelete(): void {
            this.deletedAt = new Date();
        }
        
        restore(): void {
            this.deletedAt = null;
        }
    };
}
 
// Base entity class
class BaseEntity {
    id: string = crypto.randomUUID();
}
 
// Compose mixins to create a class with multiple behaviors
const TimestampedEntity = Timestampable(BaseEntity);
const FullEntity = SoftDeletable(TimestampedEntity);
 
// Or apply both at once
class User extends SoftDeletable(Timestampable(BaseEntity)) {
    constructor(public name: string, public email: string) {
        super();
    }
}
 
// User now has all capabilities from the interfaces
const user = new User("Alice", "alice@example.com");
 
console.log(user.id);            // From BaseEntity
console.log(user.createdAt);     // From Timestampable
console.log(user.isDeleted());   // From SoftDeletable (false)
 
user.touch();                    // Update timestamp
user.softDelete();               // Soft delete
console.log(user.isDeleted());   // true
user.restore();                  // Restore
console.log(user.isDeleted());   // false
 
// Type system knows about all capabilities
function processEntity(entity: Timestampable & SoftDeletable): void {
    entity.touch();
    if (entity.isDeleted()) {
        console.log("Entity was deleted at:", entity.deletedAt);
    }
}
 
processEntity(user);  // ✅ Works - User implements both interfaces

The mixin pattern demonstrates how multiple interfaces enable horizontal reuse—sharing functionality across unrelated class hierarchies. Unlike vertical inheritance (where child gets everything from parent), mixins let you selectively compose exactly the capabilities you need.

This pattern is particularly valuable for:

Cross-cutting concerns (timestamps, soft-delete, auditing)
Feature composition without deep inheritance trees
Retrofitting capabilities onto existing class hierarchies

Real-World Multiple Interface Patterns

Let's examine how multiple interfaces are used in production systems to create flexible, well-structured code.

real-world-multi-interface.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
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
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
// ========================================
// PATTERN 1: Entity Lifecycle Interfaces
// ========================================
 
interface Identifiable {
    readonly id: string;
}
 
interface Persistable {
    save(): Promise<void>;
    refresh(): Promise<void>;
}
 
interface Validatable {
    validate(): ValidationResult;
    isValid(): boolean;
}
 
interface Serializable {
    toJSON(): object;
    fromJSON(data: object): void;
}
 
// Domain entities implement all persistence-related interfaces
class Order implements Identifiable, Persistable, Validatable, Serializable {
    readonly id: string;
    private items: OrderItem[] = [];
    private status: OrderStatus = 'draft';
    
    constructor(id?: string) {
        this.id = id ?? crypto.randomUUID();
    }
    
    // Persistable
    async save(): Promise<void> { /* Save to database */ }
    async refresh(): Promise<void> { /* Reload from database */ }
    
    // Validatable  
    validate(): ValidationResult {
        const errors: string[] = [];
        if (this.items.length === 0) errors.push("Order must have items");
        if (this.getTotal() <= 0) errors.push("Order total must be positive");
        return { valid: errors.length === 0, errors };
    }
    isValid(): boolean { return this.validate().valid; }
    
    // Serializable
    toJSON(): object {
        return { id: this.id, items: this.items, status: this.status };
    }
    fromJSON(data: object): void { /* Populate from JSON */ }
    
    // Order-specific methods
    addItem(item: OrderItem): void { this.items.push(item); }
    getTotal(): number { return this.items.reduce((sum, i) => sum + i.price, 0); }
}
 
// ========================================
// PATTERN 2: Repository with Multiple Query Interfaces
// ========================================
 
interface Readable<T, ID> {
    findById(id: ID): Promise<T | null>;
    findAll(): Promise<T[]>;
}
 
interface Writable<T, ID> {
    save(entity: T): Promise<T>;
    update(id: ID, entity: Partial<T>): Promise<T>;
    delete(id: ID): Promise<boolean>;
}
 
interface Searchable<T> {
    search(query: SearchQuery): Promise<T[]>;
    count(query: SearchQuery): Promise<number>;
}
 
interface Pageable<T> {
    findPage(page: number, size: number): Promise<Page<T>>;
}
 
// Full repository implements all query patterns
class UserRepository implements 
    Readable<User, string>, 
    Writable<User, string>, 
    Searchable<User>,
    Pageable<User> 
{
    // Readable
    async findById(id: string): Promise<User | null> { /* ... */ }
    async findAll(): Promise<User[]> { /* ... */ }
    
    // Writable
    async save(entity: User): Promise<User> { /* ... */ }
    async update(id: string, entity: Partial<User>): Promise<User> { /* ... */ }
    async delete(id: string): Promise<boolean> { /* ... */ }
    
    // Searchable
    async search(query: SearchQuery): Promise<User[]> { /* ... */ }
    async count(query: SearchQuery): Promise<number> { /* ... */ }
    
    // Pageable
    async findPage(page: number, size: number): Promise<Page<User>> { /* ... */ }
}
 
// Different parts of the app can depend on just what they need
class UserLookupService {
    constructor(private repo: Readable<User, string>) {}
    
    async getUser(id: string): Promise<User | null> {
        return this.repo.findById(id);
    }
}
 
class AdminUserService {
    constructor(private repo: Readable<User, string> & Writable<User, string>) {}
    
    async createUser(data: UserData): Promise<User> {
        const user = new User(data);
        return this.repo.save(user);
    }
}
 
// ========================================
// PATTERN 3: Event System with Multiple Concerns
// ========================================
 
interface EventHandler<T> {
    handle(event: T): Promise<void>;
}
 
interface Retryable {
    maxRetries: number;
    retryDelay: number;
}
 
interface Loggable {
    logLevel: 'debug' | 'info' | 'warn' | 'error';
    logExecution: boolean;
}
 
interface Measurable {
    recordMetrics: boolean;
    getMetrics(): HandlerMetrics;
}
 
// Critical event handlers implement all observability interfaces
class OrderCreatedHandler implements 
    EventHandler<OrderCreatedEvent>,
    Retryable,
    Loggable,
    Measurable 
{
    // Retryable
    maxRetries = 3;
    retryDelay = 1000;
    
    // Loggable
    logLevel: 'debug' | 'info' | 'warn' | 'error' = 'info';
    logExecution = true;
    
    // Measurable
    recordMetrics = true;
    private executionCount = 0;
    private totalDuration = 0;
    
    // EventHandler
    async handle(event: OrderCreatedEvent): Promise<void> {
        // Process order created event
    }
    
    getMetrics(): HandlerMetrics {
        return {
            executionCount: this.executionCount,
            averageDuration: this.totalDuration / this.executionCount
        };
    }
}

Best Practices for Multiple Interfaces

While multiple interface implementation is powerful, it requires thoughtful design to avoid complexity and maintain clarity.

Best Practices

•Keep interfaces small and focused — Each interface should represent one coherent capability. Small interfaces compose better than large ones.
•Name interfaces for capabilities, not roles — Use -able suffixes (Serializable, Comparable, Observable) to signal behavioral contracts rather than IS-A relationships.
•Group related methods logically — Methods in an interface should have high cohesion. If an interface has unrelated methods, split it.
•Consider interface segregation — If different clients need different subsets of methods, those should probably be separate interfaces.
•Document interface semantics — The contract includes behavior expectations, not just method signatures. Document what implementations should do.
•Be cautious with method count — A class implementing 15+ interfaces might be doing too much. Consider if the class has too many responsibilities.
•Use intersection types for combinations — When accepting args, use A & B to require multiple interfaces rather than creating a new combined interface.
•Avoid interface name collisions — Ensure method names across interfaces don't conflict with incompatible signatures.

Watch for Responsibility Overload

A class implementing many interfaces might be a sign of the "God Object" anti-pattern—a class that knows too much and does too much. If a class implements more than 5-7 interfaces, critically examine whether it should be split into smaller, more focused classes.

Summary: Implementing Multiple Interfaces

We've explored how a single class can implement multiple interfaces simultaneously, enabling rich polymorphic behavior and flexible design.

Key Takeaways

•Classes can implement any number of interfaces — Unlike single inheritance limits, interface implementation has no count restriction.
•Multiple interfaces enable capability composition — Objects are defined by what they can do, not what category they belong to.
•Intersection types require multiple interfaces — Use A & B to accept only objects implementing both interfaces.
•No diamond problem — Interfaces have no implementation to conflict, avoiding multiple inheritance ambiguity.
•Mixins leverage multiple interfaces — Share implementation across unrelated classes through mixin composition.
•Different views of the same object — Each interface provides a different perspective on an object's capabilities.

What's Next:

Now that we understand how to implement multiple interfaces, we'll see interface polymorphism in action through comprehensive examples. We'll explore how interface-based polymorphism enables patterns like the Strategy pattern, enables dependency injection, and creates the foundation for plugin architectures.

Page Complete

You now understand how to implement multiple interfaces and why this capability is fundamental to flexible object-oriented design. This knowledge enables composition-based designs that avoid the rigidity of deep inheritance hierarchies.

2 / 4

Loading learning content...

System Design (LLD)Polymorphism Through Interfaces

Polymorphism Through Interfaces

LevelIntermediate

Duration60 mins

TopicPolymorphism Through Interfaces

2 / 4

Implementing Multiple Interfaces

Beyond Single Inheritance

What You Will Learn

The Syntax of Multiple Implementation

Implementing multiple interfaces is syntactically straightforward. A class simply lists all the interfaces it promises to fulfill, then provides implementations for every method from every interface.

multiple-interface-syntax.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
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
// Define separate, focused interfaces
interface Printable {
    print(): string;
    getFormat(): string;
}
 
interface Saveable {
    save(path: string): Promise<void>;
    getLastSaved(): Date | null;
}
 
interface Shareable {
    share(recipient: string): Promise<boolean>;
    getShareLink(): string;
}
 
interface Exportable {
    export(format: 'pdf' | 'docx' | 'html'): Promise<Blob>;
    getSupportedFormats(): string[];
}
 
// A Document class implements ALL of these interfaces
class Document implements Printable, Saveable, Shareable, Exportable {
    private content: string;
    private lastSavedAt: Date | null = null;
    private id: string;
    
    constructor(content: string) {
        this.content = content;
        this.id = crypto.randomUUID();
    }
    
    // === Printable implementation ===
    print(): string {
        return this.content;
    }
    
    getFormat(): string {
        return 'plain-text';
    }
    
    // === Saveable implementation ===
    async save(path: string): Promise<void> {
        // Actual save logic here
        console.log(`Saving to ${path}`);
        this.lastSavedAt = new Date();
    }
    
    getLastSaved(): Date | null {
        return this.lastSavedAt;
    }
    
    // === Shareable implementation ===
    async share(recipient: string): Promise<boolean> {
        console.log(`Sharing with ${recipient}`);
        return true;
    }
    
    getShareLink(): string {
        return `https://docs.app/share/${this.id}`;
    }
    
    // === Exportable implementation ===
    async export(format: 'pdf' | 'docx' | 'html'): Promise<Blob> {
        console.log(`Exporting as ${format}`);
        return new Blob([this.content], { type: 'text/plain' });
    }
    
    getSupportedFormats(): string[] {
        return ['pdf', 'docx', 'html'];
    }
}
 
// The Document can now be used polymorphically through ANY of its interfaces
const doc = new Document("Hello, World!");
 
// As Printable
function printDocument(printable: Printable): void {
    console.log(printable.print());
}
 
// As Saveable
function autoSave(saveable: Saveable): void {
    saveable.save('/auto-save');
}
 
// As Shareable
function shareWithTeam(shareable: Shareable): void {
    shareable.share('team@company.com');
}
 
// As Exportable
function exportToPdf(exportable: Exportable): void {
    exportable.export('pdf');
}
 
// All work with the same Document instance!
printDocument(doc);
autoSave(doc);
shareWithTeam(doc);
exportToPdf(doc);

Why Multiple Interfaces Matter

Multiple interface implementation isn't just a syntactic convenience—it fundamentally changes how we design systems. It enables several powerful capabilities:

Powers of Multiple Interface Implementation

•Role-Based Access — Different parts of your system can see only the interface they need. The printing subsystem sees Printable objects; it doesn't need to know about Shareable capabilities.
•Composition Over Inheritance — Instead of complex inheritance hierarchies, you compose capabilities through interfaces. Need something that prints AND shares? Accept Printable & Shareable.
•Interface Segregation Made Easy — Each interface can be minimal and focused. Classes compose them as needed rather than implementing one large interface.
•Flexible Evolution — Add new capabilities by implementing additional interfaces. Existing code using the old interfaces continues to work.
•Test Isolation — Tests can mock exactly the interface being tested. Testing print functionality doesn't require mocking save/share/export.
•Documentation Through Types — The interfaces a class implements document its capabilities. implements Printable, Saveable, Shareable is self-documenting.

Think in Capabilities, Not Categories

role-based-access.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
65
66
67
68
69
70
// Different subsystems see different views of the same objects
 
interface Printable {
    print(): string;
}
 
interface Shareable {
    share(recipient: string): Promise<void>;
}
 
interface Deletable {
    delete(): Promise<void>;
}
 
// The Printing subsystem only knows about Printable
class PrintQueue {
    private queue: Printable[] = [];
    
    addToQueue(item: Printable): void {
        // Only sees print capability - doesn't know about share/delete
        this.queue.push(item);
    }
    
    processQueue(): void {
        this.queue.forEach(item => console.log(item.print()));
    }
}
 
// The Sharing subsystem only knows about Shareable  
class SharingService {
    async shareWithAll(items: Shareable[], recipients: string[]): Promise<void> {
        // Only sees share capability - doesn't know about print/delete
        for (const item of items) {
            for (const recipient of recipients) {
                await item.share(recipient);
            }
        }
    }
}
 
// The Cleanup subsystem only knows about Deletable
class CleanupService {
    async cleanup(items: Deletable[]): Promise<void> {
        // Only sees delete capability - doesn't know about print/share
        for (const item of items) {
            await item.delete();
        }
    }
}
 
// A Document implementing all three can be used by all subsystems
class Document implements Printable, Shareable, Deletable {
    constructor(private content: string) {}
    
    print(): string { return this.content; }
    async share(recipient: string): Promise<void> { /* ... */ }
    async delete(): Promise<void> { /* ... */ }
}
 
// Same document, different perspectives
const doc = new Document("Report Q4");
 
const printQueue = new PrintQueue();
const sharingService = new SharingService();
const cleanupService = new CleanupService();
 
// Each service only sees what it needs
printQueue.addToQueue(doc);        // Sees Printable
sharingService.shareWithAll([doc], ["team@co.com"]);  // Sees Shareable
cleanupService.cleanup([doc]);     // Sees Deletable

Intersection Types: Requiring Multiple Interfaces

intersection-types.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
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
interface Identifiable {
    getId(): string;
    getName(): string;
}
 
interface Timestamped {
    getCreatedAt(): Date;
    getUpdatedAt(): Date;
}
 
interface Auditable {
    getLastModifiedBy(): string;
    getChangeHistory(): ChangeEntry[];
}
 
interface Versionable {
    getVersion(): number;
    getPreviousVersions(): string[];
}
 
// Using intersection types to require MULTIPLE interfaces
// This function needs objects that are:
// - Identifiable (has ID and name)
// - Timestamped (has creation/update times)
// - Auditable (tracks who changed what)
function generateAuditReport(
    entity: Identifiable & Timestamped & Auditable
): AuditReport {
    return {
        entityId: entity.getId(),
        entityName: entity.getName(),
        createdAt: entity.getCreatedAt(),
        updatedAt: entity.getUpdatedAt(),
        lastModifiedBy: entity.getLastModifiedBy(),
        history: entity.getChangeHistory()
    };
}
 
// This backup function requires Identifiable + Versionable
function backupEntity(
    entity: Identifiable & Versionable
): void {
    console.log(`Backing up ${entity.getName()} v${entity.getVersion()}`);
    // Store current and previous versions
}
 
// A class implementing all four can be used with any combination
class CriticalDocument implements Identifiable, Timestamped, Auditable, Versionable {
    private id: string;
    private name: string;
    private createdAt: Date;
    private updatedAt: Date;
    private modifiedBy: string;
    private history: ChangeEntry[] = [];
    private version: number = 1;
    private previousVersions: string[] = [];
    
    constructor(name: string, createdBy: string) {
        this.id = crypto.randomUUID();
        this.name = name;
        this.createdAt = new Date();
        this.updatedAt = new Date();
        this.modifiedBy = createdBy;
    }
    
    // Identifiable
    getId(): string { return this.id; }
    getName(): string { return this.name; }
    
    // Timestamped
    getCreatedAt(): Date { return this.createdAt; }
    getUpdatedAt(): Date { return this.updatedAt; }
    
    // Auditable
    getLastModifiedBy(): string { return this.modifiedBy; }
    getChangeHistory(): ChangeEntry[] { return [...this.history]; }
    
    // Versionable
    getVersion(): number { return this.version; }
    getPreviousVersions(): string[] { return [...this.previousVersions]; }
}
 
// CriticalDocument satisfies both function requirements
const doc = new CriticalDocument("Financial Report", "alice@company.com");
 
generateAuditReport(doc);  // ✅ Works - doc is Identifiable & Timestamped & Auditable
backupEntity(doc);         // ✅ Works - doc is Identifiable & Versionable
 
// A simpler class implementing only some interfaces
class SimpleNote implements Identifiable, Timestamped {
    constructor(
        private id: string,
        private name: string,
        private createdAt: Date,
        private updatedAt: Date
    ) {}
    
    getId(): string { return this.id; }
    getName(): string { return this.name; }
    getCreatedAt(): Date { return this.createdAt; }
    getUpdatedAt(): Date { return this.updatedAt; }
}
 
const note = new SimpleNote("id-123", "Quick Note", new Date(), new Date());
 
// generateAuditReport(note);  // ❌ Error! SimpleNote is not Auditable
// backupEntity(note);         // ❌ Error! SimpleNote is not Versionable

Intersection Types Create Precision

Multiple Interfaces vs Multiple Inheritance

Many languages restrict class inheritance to a single parent to avoid the "diamond problem." But they allow multiple interface implementation without restriction. Why the difference?

The answer lies in what each provides:

Interfaces provide only contracts — They declare what methods must exist but contain no implementation. There's no conflict because there's no code to conflict with.

Multiple Inheritance vs Multiple Interfaces
Aspect	Multiple Class Inheritance	Multiple Interface Implementation
Provides	Implementation (code)	Contract (method signatures only)
Diamond Problem	Yes - conflicting implementations	No - no implementations to conflict
State Inheritance	Inherits parent state (fields)	No state inheritance
Allowed in Most Languages	No (Java, C#, TypeScript)	Yes
Cognitive Complexity	High - must understand all parent implementations	Lower - just implement declared methods
Fragile Base Class Problem	Yes - parent changes affect children	Minimal - only contract changes affect implementers

diamond-problem-avoided.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
// The Diamond Problem with Multiple Inheritance (hypothetical)
// If TypeScript allowed multiple class inheritance:
 
class Scannable {
    scan(): Image {
        console.log("Scanning using default scanner...");
        return new Image();
    }
}
 
class Faxable {
    scan(): Image {  // Same method name, different implementation!
        console.log("Scanning for fax transmission...");
        return new Image();
    }
}
 
// ❌ PROBLEM: If MultiFunctionDevice extended both,
// which scan() implementation would it inherit?
// class MultiFunctionDevice extends Scannable, Faxable { }
 
// With interfaces, there's no ambiguity:
 
interface IScanner {
    scan(): Image;
}
 
interface IFax {
    scan(): Image;  // Same signature - no problem!
    send(number: string, image: Image): void;
}
 
// The CLASS decides the implementation - there's only ONE
class MultiFunctionDevice implements IScanner, IFax {
    scan(): Image {
        // We provide THE implementation - no inheritance conflict
        console.log("Scanning via multi-function device...");
        return new Image();
    }
    
    send(number: string, image: Image): void {
        console.log(`Faxing to ${number}...`);
    }
}
 
// Both interface contracts are satisfied by the SAME method implementation
// No ambiguity, no diamond problem

Method Signature Conflicts

The Mixin Pattern with Interfaces

mixin-pattern.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
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
// Define interfaces for each capability
interface Timestampable {
    createdAt: Date;
    updatedAt: Date;
    touch(): void;
}
 
interface SoftDeletable {
    deletedAt: Date | null;
    isDeleted(): boolean;
    softDelete(): void;
    restore(): void;
}
 
// Type for a class constructor
type Constructor<T = {}> = new (...args: any[]) => T;
 
// Mixin functions that add implementation to any base class
function Timestampable<TBase extends Constructor>(Base: TBase) {
    return class extends Base implements Timestampable {
        createdAt = new Date();
        updatedAt = new Date();
        
        touch(): void {
            this.updatedAt = new Date();
        }
    };
}
 
function SoftDeletable<TBase extends Constructor>(Base: TBase) {
    return class extends Base implements SoftDeletable {
        deletedAt: Date | null = null;
        
        isDeleted(): boolean {
            return this.deletedAt !== null;
        }
        
        softDelete(): void {
            this.deletedAt = new Date();
        }
        
        restore(): void {
            this.deletedAt = null;
        }
    };
}
 
// Base entity class
class BaseEntity {
    id: string = crypto.randomUUID();
}
 
// Compose mixins to create a class with multiple behaviors
const TimestampedEntity = Timestampable(BaseEntity);
const FullEntity = SoftDeletable(TimestampedEntity);
 
// Or apply both at once
class User extends SoftDeletable(Timestampable(BaseEntity)) {
    constructor(public name: string, public email: string) {
        super();
    }
}
 
// User now has all capabilities from the interfaces
const user = new User("Alice", "alice@example.com");
 
console.log(user.id);            // From BaseEntity
console.log(user.createdAt);     // From Timestampable
console.log(user.isDeleted());   // From SoftDeletable (false)
 
user.touch();                    // Update timestamp
user.softDelete();               // Soft delete
console.log(user.isDeleted());   // true
user.restore();                  // Restore
console.log(user.isDeleted());   // false
 
// Type system knows about all capabilities
function processEntity(entity: Timestampable & SoftDeletable): void {
    entity.touch();
    if (entity.isDeleted()) {
        console.log("Entity was deleted at:", entity.deletedAt);
    }
}
 
processEntity(user);  // ✅ Works - User implements both interfaces

This pattern is particularly valuable for:

Cross-cutting concerns (timestamps, soft-delete, auditing)
Feature composition without deep inheritance trees
Retrofitting capabilities onto existing class hierarchies

Real-World Multiple Interface Patterns

Let's examine how multiple interfaces are used in production systems to create flexible, well-structured code.

real-world-multi-interface.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
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
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
// ========================================
// PATTERN 1: Entity Lifecycle Interfaces
// ========================================
 
interface Identifiable {
    readonly id: string;
}
 
interface Persistable {
    save(): Promise<void>;
    refresh(): Promise<void>;
}
 
interface Validatable {
    validate(): ValidationResult;
    isValid(): boolean;
}
 
interface Serializable {
    toJSON(): object;
    fromJSON(data: object): void;
}
 
// Domain entities implement all persistence-related interfaces
class Order implements Identifiable, Persistable, Validatable, Serializable {
    readonly id: string;
    private items: OrderItem[] = [];
    private status: OrderStatus = 'draft';
    
    constructor(id?: string) {
        this.id = id ?? crypto.randomUUID();
    }
    
    // Persistable
    async save(): Promise<void> { /* Save to database */ }
    async refresh(): Promise<void> { /* Reload from database */ }
    
    // Validatable  
    validate(): ValidationResult {
        const errors: string[] = [];
        if (this.items.length === 0) errors.push("Order must have items");
        if (this.getTotal() <= 0) errors.push("Order total must be positive");
        return { valid: errors.length === 0, errors };
    }
    isValid(): boolean { return this.validate().valid; }
    
    // Serializable
    toJSON(): object {
        return { id: this.id, items: this.items, status: this.status };
    }
    fromJSON(data: object): void { /* Populate from JSON */ }
    
    // Order-specific methods
    addItem(item: OrderItem): void { this.items.push(item); }
    getTotal(): number { return this.items.reduce((sum, i) => sum + i.price, 0); }
}
 
// ========================================
// PATTERN 2: Repository with Multiple Query Interfaces
// ========================================
 
interface Readable<T, ID> {
    findById(id: ID): Promise<T | null>;
    findAll(): Promise<T[]>;
}
 
interface Writable<T, ID> {
    save(entity: T): Promise<T>;
    update(id: ID, entity: Partial<T>): Promise<T>;
    delete(id: ID): Promise<boolean>;
}
 
interface Searchable<T> {
    search(query: SearchQuery): Promise<T[]>;
    count(query: SearchQuery): Promise<number>;
}
 
interface Pageable<T> {
    findPage(page: number, size: number): Promise<Page<T>>;
}
 
// Full repository implements all query patterns
class UserRepository implements 
    Readable<User, string>, 
    Writable<User, string>, 
    Searchable<User>,
    Pageable<User> 
{
    // Readable
    async findById(id: string): Promise<User | null> { /* ... */ }
    async findAll(): Promise<User[]> { /* ... */ }
    
    // Writable
    async save(entity: User): Promise<User> { /* ... */ }
    async update(id: string, entity: Partial<User>): Promise<User> { /* ... */ }
    async delete(id: string): Promise<boolean> { /* ... */ }
    
    // Searchable
    async search(query: SearchQuery): Promise<User[]> { /* ... */ }
    async count(query: SearchQuery): Promise<number> { /* ... */ }
    
    // Pageable
    async findPage(page: number, size: number): Promise<Page<User>> { /* ... */ }
}
 
// Different parts of the app can depend on just what they need
class UserLookupService {
    constructor(private repo: Readable<User, string>) {}
    
    async getUser(id: string): Promise<User | null> {
        return this.repo.findById(id);
    }
}
 
class AdminUserService {
    constructor(private repo: Readable<User, string> & Writable<User, string>) {}
    
    async createUser(data: UserData): Promise<User> {
        const user = new User(data);
        return this.repo.save(user);
    }
}
 
// ========================================
// PATTERN 3: Event System with Multiple Concerns
// ========================================
 
interface EventHandler<T> {
    handle(event: T): Promise<void>;
}
 
interface Retryable {
    maxRetries: number;
    retryDelay: number;
}
 
interface Loggable {
    logLevel: 'debug' | 'info' | 'warn' | 'error';
    logExecution: boolean;
}
 
interface Measurable {
    recordMetrics: boolean;
    getMetrics(): HandlerMetrics;
}
 
// Critical event handlers implement all observability interfaces
class OrderCreatedHandler implements 
    EventHandler<OrderCreatedEvent>,
    Retryable,
    Loggable,
    Measurable 
{
    // Retryable
    maxRetries = 3;
    retryDelay = 1000;
    
    // Loggable
    logLevel: 'debug' | 'info' | 'warn' | 'error' = 'info';
    logExecution = true;
    
    // Measurable
    recordMetrics = true;
    private executionCount = 0;
    private totalDuration = 0;
    
    // EventHandler
    async handle(event: OrderCreatedEvent): Promise<void> {
        // Process order created event
    }
    
    getMetrics(): HandlerMetrics {
        return {
            executionCount: this.executionCount,
            averageDuration: this.totalDuration / this.executionCount
        };
    }
}

Best Practices for Multiple Interfaces

While multiple interface implementation is powerful, it requires thoughtful design to avoid complexity and maintain clarity.

Best Practices

•Keep interfaces small and focused — Each interface should represent one coherent capability. Small interfaces compose better than large ones.
•Name interfaces for capabilities, not roles — Use -able suffixes (Serializable, Comparable, Observable) to signal behavioral contracts rather than IS-A relationships.
•Group related methods logically — Methods in an interface should have high cohesion. If an interface has unrelated methods, split it.
•Consider interface segregation — If different clients need different subsets of methods, those should probably be separate interfaces.
•Document interface semantics — The contract includes behavior expectations, not just method signatures. Document what implementations should do.
•Be cautious with method count — A class implementing 15+ interfaces might be doing too much. Consider if the class has too many responsibilities.
•Use intersection types for combinations — When accepting args, use A & B to require multiple interfaces rather than creating a new combined interface.
•Avoid interface name collisions — Ensure method names across interfaces don't conflict with incompatible signatures.

Watch for Responsibility Overload

Summary: Implementing Multiple Interfaces

We've explored how a single class can implement multiple interfaces simultaneously, enabling rich polymorphic behavior and flexible design.

Key Takeaways

•Classes can implement any number of interfaces — Unlike single inheritance limits, interface implementation has no count restriction.
•Multiple interfaces enable capability composition — Objects are defined by what they can do, not what category they belong to.
•Intersection types require multiple interfaces — Use A & B to accept only objects implementing both interfaces.
•No diamond problem — Interfaces have no implementation to conflict, avoiding multiple inheritance ambiguity.
•Mixins leverage multiple interfaces — Share implementation across unrelated classes through mixin composition.
•Different views of the same object — Each interface provides a different perspective on an object's capabilities.

What's Next:

Page Complete

2 / 4