System Design (LLD)Liskov Substitution Principle

What Is LSP?

LevelIntermediate

Duration60 mins

TopicLiskov Substitution Principle

1 / 4

Subclasses Must Be Substitutable for Base Classes

The Substitution Promise

Picture this scenario: You've built a robust payment processing system that works beautifully with CreditCardPayment objects. The system validates cards, processes transactions, handles refunds, and logs everything correctly. Your code treats every payment uniformly through a Payment base class interface.

Then a colleague introduces CryptocurrencyPayment as a subclass of Payment. It inherits from the same base class, so it should "just work," right? You deploy to production. Within hours, your refund system crashes because cryptocurrency payments throw UnsupportedOperationException on refunds. Your validation logic fails silently because crypto payments ignore the validation method entirely. Your logging breaks because crypto payments return null for transaction IDs.

Your system trusted that subclasses would behave like the base class. That trust was violated.

This is exactly the kind of failure the Liskov Substitution Principle (LSP) is designed to prevent.

What You Will Learn

By the end of this page, you will understand LSP's core definition—what substitutability means, why it matters, and how violations create subtle yet devastating bugs. You'll learn to think about inheritance not as code reuse, but as a behavioral contract between types.

The Core Definition of LSP

The Liskov Substitution Principle can be stated simply:

If S is a subtype of T, then objects of type T may be replaced with objects of type S without altering any of the desirable properties of the program.

Let's unpack what this really means. The principle demands that anywhere your code expects a Parent type, you should be able to pass any Child type without the code breaking, behaving unexpectedly, or requiring special handling.

The Substitution Test

Here's a practical test for LSP: If you have to check instanceof or the specific subtype to make your code work correctly, you're likely violating LSP. The whole point is that the caller shouldn't need to know which specific subtype they're dealing with.

What "substitutable" actually means:

Substitutability isn't just about syntax—it's about behavior. A subclass is truly substitutable only if it:

Accepts at least everything the parent accepts — The subclass cannot reject inputs that the parent would accept
Produces outputs within the parent's range — The subclass cannot return values the parent would never return
Maintains all guarantees the parent makes — If the parent promises certain behavior, the subclass must honor it
Preserves the parent's invariants — Properties that are always true for the parent must remain true for the subclass

When any of these conditions are violated, code that works with the parent type will fail when given the subclass—often in subtle, hard-to-diagnose ways.

substitutability-example
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
// Base class establishes a contract
abstract class Bird {
    abstract fly(): void;
    abstract makeSound(): string;
}
 
// Sparrow is fully substitutable - it honors all contracts
class Sparrow extends Bird {
    fly(): void {
        console.log("Sparrow flies through the air");
    }
    
    makeSound(): string {
        return "Chirp chirp!";
    }
}
 
// Penguin violates LSP - it cannot fulfill the fly() contract
class Penguin extends Bird {
    fly(): void {
        // VIOLATION: Throws instead of flying
        throw new Error("Penguins cannot fly!");
    }
    
    makeSound(): string {
        return "Honk!";
    }
}
 
// Client code written against the base class
function releaseBirds(birds: Bird[]): void {
    for (const bird of birds) {
        // This code TRUSTS that all Birds can fly
        bird.fly();  // Crashes when bird is a Penguin!
    }
}
 
// The problem: Penguin IS-A Bird syntactically, but NOT behaviorally
const flock: Bird[] = [new Sparrow(), new Penguin()];
releaseBirds(flock);  // Runtime explosion

The Bird/Penguin example is classic because it reveals a fundamental truth: inheritance should model behavioral compatibility, not just taxonomic classification.

In biology, penguins are indeed birds. But in software, inheritance implies more than classification—it implies that the child can do everything the parent can do. A Penguin that throws an exception when asked to fly breaks this contract.

Why Substitutability Matters

What's the big deal if one subclass doesn't quite fit? The consequences ripple through your entire codebase in ways that are often invisible until they cause production incidents.

The trust problem:

When code is written against an abstraction (a base class or interface), it makes assumptions about behavior. These assumptions are implicit contracts:

If I call save(), the data will be persisted
If I call validate(), I'll get a boolean indicating validity
If I call calculate(), I'll get a numeric result within expected bounds

Every piece of code that uses the abstraction depends on these contracts. When a subclass violates them, it doesn't just break one function—it potentially breaks every function that uses that abstraction.

Impact of LSP Violations
Violation Type	Immediate Effect	Cascading Consequences
Method throws unexpected exception	Caller crashes without handling	Uncaught exceptions propagate up the stack; system instability
Method silently does nothing	Operation appears successful but isn't	Data corruption; inconsistent state; debugging nightmares
Method returns unexpected value/type	Caller logic operates on bad data	Wrong decisions propagate; subtle calculation errors
Method has side effects parent doesn't have	Unexpected mutations occur	Race conditions; resource leaks; security vulnerabilities
Method requires preconditions parent doesn't	Caller fails to provide them	Random failures depending on input; intermittent bugs

The Invisible Bug Factory

LSP violations often don't cause immediate crashes. They cause wrong behavior that appears correct. Your system continues running, but it's making wrong decisions, corrupting data, or creating technical debt invisibly. These are the bugs that take weeks to diagnose.

The polymorphism foundation:

Polymorphism—the ability to write code that works with any object in a type hierarchy—is one of object-oriented programming's greatest powers. But polymorphism only works if substitutability is guaranteed.

Consider this chain of logic:

I write code that accepts Shape
I can pass Circle, Rectangle, Triangle without changing my code
My code doesn't know or care which specific shape it's handling
The system is extensible—new shapes can be added without modifying existing code

This beautiful property collapses the moment one shape violates the contract. If InvalidShape throws exceptions or returns null where others return values, my generic code breaks. I'm forced to add instanceof checks. Polymorphism degrades into switch statements. The architecture unravels.

What LSP Enables

•Fearless refactoring — You can replace one implementation with another, confident the system won't break
•Genuine abstraction — Code can truly be written against interfaces, not implementations
•Safe extension — New subclasses can be added without touching existing code
•Testable design — Mock objects can substitute for real ones during testing
•Framework trust — Libraries can provide extension points that users can safely implement

Substitutability vs. Type Compatibility

A critical distinction: Your compiler or type checker verifying that Child extends Parent is not the same as LSP compliance. LSP is about behavioral compatibility, not syntactic compatibility.

The compiler checks:

Does this class have all required methods?
Do the method signatures match?
Are the return types compatible?

LSP additionally requires:

Does this implementation behave consistently with the parent?
Does it honor implicit contracts?
Does it preserve invariants?

Compiler Checks

•Method exists in subclass
•Parameter types are compatible
•Return type is compatible
•Access modifiers are valid
•No missing abstract implementations

LSP Requires Additionally

•Method behavior matches parent's contract
•No unexpected exceptions thrown
•Output values within expected ranges
•No strengthened preconditions
•Parent's invariants maintained

type-vs-behavior
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
// TYPE-COMPATIBLE but NOT LSP-COMPLIANT
 
interface Stack<T> {
    push(item: T): void;
    pop(): T | undefined;
    peek(): T | undefined;
    size(): number;
}
 
// This implementation is type-compatible
class LimitedStack<T> implements Stack<T> {
    private items: T[] = [];
    private readonly maxSize: number = 10;
    
    push(item: T): void {
        // VIOLATION: Silently ignores items beyond limit
        // Parent contract implies push always adds the item
        if (this.items.length < this.maxSize) {
            this.items.push(item);
        }
        // No error, no indication - item just disappears
    }
    
    pop(): T | undefined {
        return this.items.pop();
    }
    
    peek(): T | undefined {
        return this.items[this.items.length - 1];
    }
    
    size(): number {
        return this.items.length;
    }
}
 
// Client code that trusts the Stack contract
function processItems<T>(stack: Stack<T>, items: T[]): void {
    for (const item of items) {
        stack.push(item);
    }
    console.log(`Pushed ${items.length} items, stack size: ${stack.size()}`);
}
 
// Works as expected with regular stack
// With LimitedStack: "Pushed 100 items, stack size: 10" - DATA LOSS!

The Type System Can't Save You

The LimitedStack compiles perfectly. TypeScript, Python, Java—none of them will catch this bug. The violation is behavioral, not syntactic. This is why LSP requires programmer discipline beyond what any type system can verify.

The fix requires behavioral alignment:

If LimitedStack can't accept all items, it must signal this clearly:

Throw an exception when full (explicit failure)
Return a boolean indicating success (explicit result)
Use a different interface (BoundedStack) that documents the limit

The key is that client code must not be surprised. Either the subclass behaves exactly like the parent, or it uses a different type that communicates its different behavior.

The Hierarchy Design Problem

LSP violations often stem from a fundamental mistake: using inheritance for reasons other than behavioral compatibility.

Common misuses of inheritance:

Wrong Reasons to Inherit

•Code reuse — "I want to reuse some methods" → Use composition instead
•Taxonomic classification — "In the real world, X is a type of Y" → Software models behavior, not biology
•Reducing duplication — "These classes share some fields" → Extract a shared component
•Fitting into a framework — "The framework expects this class" → Consider adapters or decorators
•Convenience — "It's easier to extend than write from scratch" → Technical debt accumulates

The right reason to inherit:

Inheritance should be used when and only when the child genuinely is a specialization of the parent in terms of behavior. The child should:

Be able to fulfill every responsibility of the parent
Add new capabilities without modifying existing ones
Represent a true conceptual specialization

Let's examine a properly designed hierarchy:

proper-hierarchy
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
// Well-designed: ReadOnlyCollection is genuinely substitutable
interface Collection<T> {
    size(): number;
    contains(item: T): boolean;
    iterator(): Iterator<T>;
}
 
// ReadOnlyList IS-A Collection - fully substitutable
interface ReadOnlyList<T> extends Collection<T> {
    get(index: number): T;
    indexOf(item: T): number;
}
 
// Separate interface for mutation - doesn't force immutable types to lie
interface MutableCollection<T> extends Collection<T> {
    add(item: T): boolean;
    remove(item: T): boolean;
    clear(): void;
}
 
// ArrayList implements both - it can do everything both contracts require
class ArrayList<T> implements ReadOnlyList<T>, MutableCollection<T> {
    private items: T[] = [];
    
    size(): number { return this.items.length; }
    contains(item: T): boolean { return this.items.includes(item); }
    get(index: number): T { return this.items[index]; }
    indexOf(item: T): number { return this.items.indexOf(item); }
    add(item: T): boolean { this.items.push(item); return true; }
    remove(item: T): boolean {
        const idx = this.items.indexOf(item);
        if (idx >= 0) { this.items.splice(idx, 1); return true; }
        return false;
    }
    clear(): void { this.items = []; }
    iterator(): Iterator<T> { return this.items[Symbol.iterator](); }
}
 
// ImmutableList implements ONLY ReadOnlyList - honest about its capabilities
class ImmutableList<T> implements ReadOnlyList<T> {
    private readonly items: readonly T[];
    
    constructor(items: T[]) { this.items = [...items]; }
    
    size(): number { return this.items.length; }
    contains(item: T): boolean { return this.items.includes(item); }
    get(index: number): T { return this.items[index]; }
    indexOf(item: T): number { return this.items.indexOf(item); }
    iterator(): Iterator<T> { return this.items[Symbol.iterator](); }
    
    // No mutation methods - ImmutableList doesn't pretend to be mutable
}
 
// Both are safely substitutable for ReadOnlyList!
function countLargeItems<T>(list: ReadOnlyList<T>, predicate: (t: T) => boolean): number {
    let count = 0;
    const iter = list.iterator();
    let result = iter.next();
    while (!result.done) {
        if (predicate(result.value)) count++;
        result = iter.next();
    }
    return count;
}

Honest Type Hierarchies

Notice how ImmutableList doesn't implement MutableCollection and pretend mutations work. It only claims to be what it truly is. This is LSP-compliant design: types only promise what they can deliver.

Recognizing Substitutability Failures

How do you know if your hierarchy has substitutability problems? Watch for these warning signs in your codebase:

Red Flags in Your Code

•instanceof checks before method calls — If you need to know the concrete type to call a method safely, substitutability is broken
•Empty or exception-throwing method overrides — Methods that say "I can't do this" reveal a bad hierarchy
•Methods that return special values for some subtypes — Returning null, -1, or empty results where parent returns meaningful data
•Documentation warning about specific subtypes — "Note: This doesn't work with X subclass" is a confession of LSP violation
•Defensive code in callers — Try-catch blocks around polymorphic calls; null checks on results that shouldn't be null
•Flags or type fields controlling behavior — When the object needs to tell callers what it can or can't do

lsp-violation-smells
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
// SMELL 1: instanceof before method call
function processDocument(doc: Document): void {
    // If you need to check the type, LSP is violated
    if (doc instanceof PdfDocument) {
        doc.renderWithPdfRenderer();
    } else if (doc instanceof WordDocument) {
        doc.renderWithWordRenderer();
    } else {
        // What about new document types?
        throw new Error("Unknown document type");
    }
}
 
// SMELL 2: Empty method override
class ReadOnlyRepository extends Repository {
    override save(entity: Entity): void {
        // Does nothing - violates parent contract
    }
    
    override delete(id: string): void {
        throw new Error("Cannot delete from read-only repository");
    }
}
 
// SMELL 3: Type flags controlling behavior
class Shape {
    supportsRotation: boolean = true;
    
    rotate(degrees: number): void {
        if (!this.supportsRotation) {
            throw new Error("Rotation not supported");
        }
        // Actual rotation logic
    }
}
 
class Line extends Shape {
    constructor() {
        super();
        this.supportsRotation = false;  // Reveals LSP violation
    }
}
 
// SMELL 4: Try-catch around polymorphic calls
function exportAllShapes(shapes: Shape[]): void {
    for (const shape of shapes) {
        try {
            shape.export();  // Some shapes throw here
        } catch (e) {
            console.log(`Skipping ${shape.constructor.name}: export not supported`);
        }
    }
}

Each of these smells indicates the same underlying problem: the inheritance hierarchy doesn't represent true behavioral compatibility. The code is forced to work around the fact that not all subclasses are truly substitutable.

The Refactoring Hint

When you see these patterns, it's usually a sign that you need either (1) a different hierarchy where subtypes don't inherit capabilities they don't have, (2) smaller, more focused interfaces that subtypes can honestly implement, or (3) composition instead of inheritance.

Summary: The Substitution Contract

We've established the foundational understanding of what LSP means and why it matters. Let's crystallize the key insights:

Key Takeaways

•LSP is about behavior, not syntax — A subclass must behave consistently with its parent, not just compile against it
•Substitutability enables polymorphism — Without LSP, generic code falls apart into type-checking cascades
•The compiler can't verify LSP — Behavioral contracts are implicit; programmers must enforce them
•Inheritance means 'can do everything parent does' — Not 'is taxonomically related' or 'shares some code'
•Warning signs are visible — instanceof, empty overrides, defensive try-catch blocks all signal violations
•Good hierarchies are honest — Types only inherit interfaces they can fully implement

What's next:

We've established the conceptual foundation. The next page dives into Barbara Liskov's original formulation of this principle—the precise, rigorous definition that computer scientists use. Understanding her formulation will give you the analytical tools to reason about substitutability with precision.

Page Complete

You now understand LSP's core definition: subclasses must be fully substitutable for their base classes. This isn't about satisfying a type checker—it's about ensuring behavioral compatibility that makes polymorphism work. Next, we'll explore Barbara Liskov's formal articulation of this principle.

1 / 4

Loading learning content...

System Design (LLD)Liskov Substitution Principle

What Is LSP?

LevelIntermediate

Duration60 mins

TopicLiskov Substitution Principle

1 / 4

Subclasses Must Be Substitutable for Base Classes

The Substitution Promise

Your system trusted that subclasses would behave like the base class. That trust was violated.

This is exactly the kind of failure the Liskov Substitution Principle (LSP) is designed to prevent.

What You Will Learn

The Core Definition of LSP

The Liskov Substitution Principle can be stated simply:

If S is a subtype of T, then objects of type T may be replaced with objects of type S without altering any of the desirable properties of the program.

The Substitution Test

What "substitutable" actually means:

Substitutability isn't just about syntax—it's about behavior. A subclass is truly substitutable only if it:

Accepts at least everything the parent accepts — The subclass cannot reject inputs that the parent would accept
Produces outputs within the parent's range — The subclass cannot return values the parent would never return
Maintains all guarantees the parent makes — If the parent promises certain behavior, the subclass must honor it
Preserves the parent's invariants — Properties that are always true for the parent must remain true for the subclass

When any of these conditions are violated, code that works with the parent type will fail when given the subclass—often in subtle, hard-to-diagnose ways.

substitutability-example
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
// Base class establishes a contract
abstract class Bird {
    abstract fly(): void;
    abstract makeSound(): string;
}
 
// Sparrow is fully substitutable - it honors all contracts
class Sparrow extends Bird {
    fly(): void {
        console.log("Sparrow flies through the air");
    }
    
    makeSound(): string {
        return "Chirp chirp!";
    }
}
 
// Penguin violates LSP - it cannot fulfill the fly() contract
class Penguin extends Bird {
    fly(): void {
        // VIOLATION: Throws instead of flying
        throw new Error("Penguins cannot fly!");
    }
    
    makeSound(): string {
        return "Honk!";
    }
}
 
// Client code written against the base class
function releaseBirds(birds: Bird[]): void {
    for (const bird of birds) {
        // This code TRUSTS that all Birds can fly
        bird.fly();  // Crashes when bird is a Penguin!
    }
}
 
// The problem: Penguin IS-A Bird syntactically, but NOT behaviorally
const flock: Bird[] = [new Sparrow(), new Penguin()];
releaseBirds(flock);  // Runtime explosion

The Bird/Penguin example is classic because it reveals a fundamental truth: inheritance should model behavioral compatibility, not just taxonomic classification.

Why Substitutability Matters

What's the big deal if one subclass doesn't quite fit? The consequences ripple through your entire codebase in ways that are often invisible until they cause production incidents.

The trust problem:

When code is written against an abstraction (a base class or interface), it makes assumptions about behavior. These assumptions are implicit contracts:

If I call save(), the data will be persisted
If I call validate(), I'll get a boolean indicating validity
If I call calculate(), I'll get a numeric result within expected bounds

Impact of LSP Violations
Violation Type	Immediate Effect	Cascading Consequences
Method throws unexpected exception	Caller crashes without handling	Uncaught exceptions propagate up the stack; system instability
Method silently does nothing	Operation appears successful but isn't	Data corruption; inconsistent state; debugging nightmares
Method returns unexpected value/type	Caller logic operates on bad data	Wrong decisions propagate; subtle calculation errors
Method has side effects parent doesn't have	Unexpected mutations occur	Race conditions; resource leaks; security vulnerabilities
Method requires preconditions parent doesn't	Caller fails to provide them	Random failures depending on input; intermittent bugs

The Invisible Bug Factory

The polymorphism foundation:

Consider this chain of logic:

I write code that accepts Shape
I can pass Circle, Rectangle, Triangle without changing my code
My code doesn't know or care which specific shape it's handling
The system is extensible—new shapes can be added without modifying existing code

What LSP Enables

•Fearless refactoring — You can replace one implementation with another, confident the system won't break
•Genuine abstraction — Code can truly be written against interfaces, not implementations
•Safe extension — New subclasses can be added without touching existing code
•Testable design — Mock objects can substitute for real ones during testing
•Framework trust — Libraries can provide extension points that users can safely implement

Substitutability vs. Type Compatibility

A critical distinction: Your compiler or type checker verifying that Child extends Parent is not the same as LSP compliance. LSP is about behavioral compatibility, not syntactic compatibility.

The compiler checks:

Does this class have all required methods?
Do the method signatures match?
Are the return types compatible?

LSP additionally requires:

Does this implementation behave consistently with the parent?
Does it honor implicit contracts?
Does it preserve invariants?

Compiler Checks

•Method exists in subclass
•Parameter types are compatible
•Return type is compatible
•Access modifiers are valid
•No missing abstract implementations

LSP Requires Additionally

•Method behavior matches parent's contract
•No unexpected exceptions thrown
•Output values within expected ranges
•No strengthened preconditions
•Parent's invariants maintained

type-vs-behavior
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
// TYPE-COMPATIBLE but NOT LSP-COMPLIANT
 
interface Stack<T> {
    push(item: T): void;
    pop(): T | undefined;
    peek(): T | undefined;
    size(): number;
}
 
// This implementation is type-compatible
class LimitedStack<T> implements Stack<T> {
    private items: T[] = [];
    private readonly maxSize: number = 10;
    
    push(item: T): void {
        // VIOLATION: Silently ignores items beyond limit
        // Parent contract implies push always adds the item
        if (this.items.length < this.maxSize) {
            this.items.push(item);
        }
        // No error, no indication - item just disappears
    }
    
    pop(): T | undefined {
        return this.items.pop();
    }
    
    peek(): T | undefined {
        return this.items[this.items.length - 1];
    }
    
    size(): number {
        return this.items.length;
    }
}
 
// Client code that trusts the Stack contract
function processItems<T>(stack: Stack<T>, items: T[]): void {
    for (const item of items) {
        stack.push(item);
    }
    console.log(`Pushed ${items.length} items, stack size: ${stack.size()}`);
}
 
// Works as expected with regular stack
// With LimitedStack: "Pushed 100 items, stack size: 10" - DATA LOSS!

The Type System Can't Save You

The fix requires behavioral alignment:

If LimitedStack can't accept all items, it must signal this clearly:

Throw an exception when full (explicit failure)
Return a boolean indicating success (explicit result)
Use a different interface (BoundedStack) that documents the limit

The key is that client code must not be surprised. Either the subclass behaves exactly like the parent, or it uses a different type that communicates its different behavior.

The Hierarchy Design Problem

LSP violations often stem from a fundamental mistake: using inheritance for reasons other than behavioral compatibility.

Common misuses of inheritance:

Wrong Reasons to Inherit

•Code reuse — "I want to reuse some methods" → Use composition instead
•Taxonomic classification — "In the real world, X is a type of Y" → Software models behavior, not biology
•Reducing duplication — "These classes share some fields" → Extract a shared component
•Fitting into a framework — "The framework expects this class" → Consider adapters or decorators
•Convenience — "It's easier to extend than write from scratch" → Technical debt accumulates

The right reason to inherit:

Inheritance should be used when and only when the child genuinely is a specialization of the parent in terms of behavior. The child should:

Be able to fulfill every responsibility of the parent
Add new capabilities without modifying existing ones
Represent a true conceptual specialization

Let's examine a properly designed hierarchy:

proper-hierarchy
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
// Well-designed: ReadOnlyCollection is genuinely substitutable
interface Collection<T> {
    size(): number;
    contains(item: T): boolean;
    iterator(): Iterator<T>;
}
 
// ReadOnlyList IS-A Collection - fully substitutable
interface ReadOnlyList<T> extends Collection<T> {
    get(index: number): T;
    indexOf(item: T): number;
}
 
// Separate interface for mutation - doesn't force immutable types to lie
interface MutableCollection<T> extends Collection<T> {
    add(item: T): boolean;
    remove(item: T): boolean;
    clear(): void;
}
 
// ArrayList implements both - it can do everything both contracts require
class ArrayList<T> implements ReadOnlyList<T>, MutableCollection<T> {
    private items: T[] = [];
    
    size(): number { return this.items.length; }
    contains(item: T): boolean { return this.items.includes(item); }
    get(index: number): T { return this.items[index]; }
    indexOf(item: T): number { return this.items.indexOf(item); }
    add(item: T): boolean { this.items.push(item); return true; }
    remove(item: T): boolean {
        const idx = this.items.indexOf(item);
        if (idx >= 0) { this.items.splice(idx, 1); return true; }
        return false;
    }
    clear(): void { this.items = []; }
    iterator(): Iterator<T> { return this.items[Symbol.iterator](); }
}
 
// ImmutableList implements ONLY ReadOnlyList - honest about its capabilities
class ImmutableList<T> implements ReadOnlyList<T> {
    private readonly items: readonly T[];
    
    constructor(items: T[]) { this.items = [...items]; }
    
    size(): number { return this.items.length; }
    contains(item: T): boolean { return this.items.includes(item); }
    get(index: number): T { return this.items[index]; }
    indexOf(item: T): number { return this.items.indexOf(item); }
    iterator(): Iterator<T> { return this.items[Symbol.iterator](); }
    
    // No mutation methods - ImmutableList doesn't pretend to be mutable
}
 
// Both are safely substitutable for ReadOnlyList!
function countLargeItems<T>(list: ReadOnlyList<T>, predicate: (t: T) => boolean): number {
    let count = 0;
    const iter = list.iterator();
    let result = iter.next();
    while (!result.done) {
        if (predicate(result.value)) count++;
        result = iter.next();
    }
    return count;
}

Honest Type Hierarchies

Notice how ImmutableList doesn't implement MutableCollection and pretend mutations work. It only claims to be what it truly is. This is LSP-compliant design: types only promise what they can deliver.

Recognizing Substitutability Failures

How do you know if your hierarchy has substitutability problems? Watch for these warning signs in your codebase:

Red Flags in Your Code

•instanceof checks before method calls — If you need to know the concrete type to call a method safely, substitutability is broken
•Empty or exception-throwing method overrides — Methods that say "I can't do this" reveal a bad hierarchy
•Methods that return special values for some subtypes — Returning null, -1, or empty results where parent returns meaningful data
•Documentation warning about specific subtypes — "Note: This doesn't work with X subclass" is a confession of LSP violation
•Defensive code in callers — Try-catch blocks around polymorphic calls; null checks on results that shouldn't be null
•Flags or type fields controlling behavior — When the object needs to tell callers what it can or can't do

lsp-violation-smells
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
// SMELL 1: instanceof before method call
function processDocument(doc: Document): void {
    // If you need to check the type, LSP is violated
    if (doc instanceof PdfDocument) {
        doc.renderWithPdfRenderer();
    } else if (doc instanceof WordDocument) {
        doc.renderWithWordRenderer();
    } else {
        // What about new document types?
        throw new Error("Unknown document type");
    }
}
 
// SMELL 2: Empty method override
class ReadOnlyRepository extends Repository {
    override save(entity: Entity): void {
        // Does nothing - violates parent contract
    }
    
    override delete(id: string): void {
        throw new Error("Cannot delete from read-only repository");
    }
}
 
// SMELL 3: Type flags controlling behavior
class Shape {
    supportsRotation: boolean = true;
    
    rotate(degrees: number): void {
        if (!this.supportsRotation) {
            throw new Error("Rotation not supported");
        }
        // Actual rotation logic
    }
}
 
class Line extends Shape {
    constructor() {
        super();
        this.supportsRotation = false;  // Reveals LSP violation
    }
}
 
// SMELL 4: Try-catch around polymorphic calls
function exportAllShapes(shapes: Shape[]): void {
    for (const shape of shapes) {
        try {
            shape.export();  // Some shapes throw here
        } catch (e) {
            console.log(`Skipping ${shape.constructor.name}: export not supported`);
        }
    }
}

The Refactoring Hint

Summary: The Substitution Contract

We've established the foundational understanding of what LSP means and why it matters. Let's crystallize the key insights:

Key Takeaways

•LSP is about behavior, not syntax — A subclass must behave consistently with its parent, not just compile against it
•Substitutability enables polymorphism — Without LSP, generic code falls apart into type-checking cascades
•The compiler can't verify LSP — Behavioral contracts are implicit; programmers must enforce them
•Inheritance means 'can do everything parent does' — Not 'is taxonomically related' or 'shares some code'
•Warning signs are visible — instanceof, empty overrides, defensive try-catch blocks all signal violations
•Good hierarchies are honest — Types only inherit interfaces they can fully implement

What's next:

Page Complete

1 / 4