Liskov substitution L

01 / MEET THE PRINCIPLE

What is Liskov substitution?

A replacement type must preserve the behaviour that callers are entitled to expect from the original contract.

First understand the idea. Then explore why it helps, before bringing it to life in the harbour.

WHERE THE IDEA BEGAN

A little history.

Barbara Liskov discussed data abstraction and hierarchy in 1987. Her work with Jeannette Wing formalised behavioural subtyping in their 1994 paper A Behavioral Notion of Subtyping.

02 / WHY IT MATTERS

Why use it?

Where it helps

Useful whenever callers depend on a base class or interface: storage providers, payment adapters and test doubles must preserve the agreed behaviour.

Why use it?

Callers can rely on the contract without asking which implementation they received. This includes valid inputs, promised outputs and relevant state rules—not just method signatures.

What if you ignore it?

A caller passes a valid input and gets an unexpected refusal, missing result or changed state. Defensive type checks then spread through code that should have been able to trust the abstraction.

KNOW THE TRADE-OFF

Useful, not absolute.

This is not a rule that every real-world category needs inheritance. Composition or a smaller, accurate contract may be better. Expected, documented errors do not automatically violate LSP.

Next, step into the story and see this problem through a familiar situation.

03 / ONCE UPON A CHANGE

A ferry must
keep its promise.

The crossing promises to carry any parcel up to 20 kg and issue a delivery receipt. The harbour swaps its ferry for a tiny rowboat that quietly refuses anything above 5 kg. Both are boats, but the replacement breaks the promise.

Sharing a name or shape is not enough. A substitute must honour the same accepted inputs and promised results. Give the rowboat a different contract if it cannot do that job.

Turn to “Try it” to change the design and see what happens.

04 / PULL THE PAPER TAB

What happens
when things change?

The replacement secretly accepts only up to 5 kg.

The replacement secretly accepts only up to 5 kg.

Choose a scenario, then try the change.

An illustrative model, not a benchmark or a claim that every design change causes a bug.

05 / FROM STORY TO CODE

Spot the dependency.

A replacement type must preserve the behaviour that callers are entitled to expect from the original contract.

Before

// Contract: weights from 0 to 20 kg are accepted.
Receipt Cross(decimal kg)
{
    if (kg > 5m) throw new NotSupportedException();
    return Deliver(kg); // breaks the 20 kg promise
}

A MORE FOCUSED DESIGN

After

// A conforming implementation keeps the contract.
Receipt Cross(decimal kg)
{
    if (kg < 0m || kg > 20m)
        throw new ArgumentOutOfRangeException();
    return Deliver(kg); // returns the promised receipt
}

Illustrative C# sketches. Supporting types and method bodies are omitted; these snippets are not executed in the page.

06 / MAKE IT STICK

Take the idea
with you.

A replacement type must preserve the behaviour that callers are entitled to expect from the original contract.

Try the question opposite, then continue to the next principle.