Think about AA batteries. It doesn’t matter which brand you buy — every single one fits into the same slot, pushes power the same direction, and makes your torch, remote control, or toy car work exactly the way it’s supposed to. You never have to open the battery compartment and check the label before you trust it to do its job. That trust is the whole point.

Now imagine a company invented a “battery” that fit the same slot perfectly but, instead of producing electricity, played a tiny tune. It looks like a battery. It clicks into place like a battery. But the moment you rely on it to power your torch, everything breaks. It technically fits — yet it can’t be trusted to behave like the thing it’s pretending to be.

That is precisely the problem the Liskov Substitution Principle — usually shortened to LSP — was created to prevent, except instead of batteries and torches, it’s talking about classes and objects in a computer program. LSP is the third principle in the famous SOLID set of object-oriented design principles, and it’s named after Barbara Liskov, a computer scientist who first described the idea in a keynote speech in 1987. Her core message, boiled down to one sentence, is this: if one type of object claims to be a more specific version of another, it must be safe to swap the two without anything going wrong.

Barbara Liskov’s original wording was fairly technical and mathematical, written for an audience of researchers. Over the years, engineers have translated it into a version that’s much easier to hold onto: objects of a parent (or “base”) type should be replaceable with objects of any of its child (or “sub”) types, without changing whether the program behaves correctly.

In plainer words still: if your code was written to work with a “Shape,” it should keep working — without any special-case checks — no matter whether you hand it a Circle, a Square, or a Triangle, as long as all three are declared as Shapes. The moment your code needs to ask “wait, is this actually a Circle or a Square before I can trust it?”, something about the design has gone wrong.

Two smaller ideas sit underneath that big one. First, substitutability is about behaviour, not just structure — a subclass can have all the right method names and the right inputs and outputs on paper, and still violate LSP if it behaves differently underneath. Second, a subtype should only ever specialise, never contradict, the promises made by its parent. It’s allowed to do more; it’s never allowed to do less, or to do something different while pretending it’s the same thing.

Barbara Liskov didn’t invent this idea in isolation — she was one of the pioneers of a whole way of thinking about software called abstract data types, which is really just a fancy name for “types that hide how they work internally and only promise what they do.” Long before most programming languages even had classes and inheritance, Liskov was already asking a deceptively simple question: if I build a new type using an old one, how do I know the new type still keeps every promise the old one made?

She first raised this question publicly in a keynote speech in 1987, at a conference about object-oriented programming. It wasn’t originally called “the Liskov Substitution Principle” at all — that catchy name came later, once other engineers started referencing her idea so often that it needed a memorable label. In 1994, Liskov teamed up with fellow computer scientist Jeannette Wing to write it up formally, describing precisely what it means for one type to be a trustworthy “behavioural subtype” of another.

Around the same time, a related idea was taking shape under a different name: Design by Contract, popularised by computer scientist Bertrand Meyer through the Eiffel programming language. Design by Contract treats every method as if it were a legal agreement — spelling out preconditions, postconditions, and invariants explicitly, sometimes even checking them automatically while the program runs. LSP and Design by Contract grew up side by side, reinforcing the same underlying truth: good software isn’t just about what a method does when everything goes right — it’s about the promises it makes, and never quietly breaking them.

You might wonder — so what if a subclass behaves a little differently? In small projects, it might genuinely not matter much. But the moment a codebase grows, gets touched by more than one engineer, and starts depending on inheritance to add new features, LSP becomes one of the quiet forces holding the whole thing together. Here’s what following it actually buys a team:

There’s also a very practical, everyday reason this matters: teams almost never work with just one version of a “Shape,” a “Payment Method,” or a “User Account.” New subtypes get added constantly as a product grows — new payment providers, new device types, new user roles. If the very first version of the base type was designed carelessly, every single new subtype added later inherits that same shaky foundation, and the problem compounds year after year instead of fading away.

Picture a small online store that started with a single Payment class, used only for credit cards. Eighteen months later, the same class has been quietly stretched to also represent gift cards, wallet balances, and buy-now-pay-later plans — none of which can honestly support every promise the original class made, like “refund() always returns the money to the original source instantly.” Engineers start adding “if this payment type is a gift card, skip this step” checks throughout the checkout flow, and within a year, nobody on the team fully trusts the Payment class anymore. That slow erosion of trust, multiplied across dozens of classes in a large system, is what LSP quietly exists to prevent.

Here’s a helpful way to picture it. Imagine every class in your program has quietly signed an invisible contract with everyone who will ever use it. That contract has three parts, and understanding them is the real key to understanding LSP.

1. Preconditions — what must be true before a piece of code runs. (“You must hand me a positive number.”)
2. Postconditions — what is guaranteed to be true after the code finishes. (“I promise to return a sorted list.”)
3. Invariants — things that must always stay true, no matter what happens in between. (“The bank balance can never go below zero.”)

LSP adds a simple, strict rule on top of this contract: a subclass is allowed to loosen preconditions (ask for less than the parent did) but never tighten them (ask for more). It’s allowed to strengthen postconditions (promise more than the parent did) but never weaken them (promise less). And it must never break an invariant the parent guaranteed, under any circumstance.

In real codebases, these contracts are rarely written down as formally as a legal document — they usually live as comments, as documentation, or simply as the shared understanding a team builds over time. That’s exactly why tests matter so much here. A well-written test doesn’t just check “does this method return the right answer for one example” — a good LSP-aware test checks “does this method still honour every precondition, postcondition, and invariant the base type promised, even for a subtype nobody has written yet.” Teams that write their tests against the base type’s contract, rather than against one specific subclass, end up with a safety net that automatically protects every future subtype too.

When people study LSP closely, they usually find it helpful to split the rules into two families. One family can often be checked automatically by the programming language itself. The other family cannot — no compiler in the world can catch it, which is exactly why it causes so many hidden bugs.

Signature rules are the easy half. Most modern languages already stop you from, say, overriding a method and suddenly requiring a completely different type of input — the compiler simply won’t let the code build. This is why so many engineers assume that once their code compiles cleanly, LSP is automatically satisfied. It isn’t. A subclass can have a perfectly matching signature and still lie about what it actually does once it starts running — and that lie is where nearly every real LSP violation lives.

Inside the signature rules, there are two smaller, slightly technical ideas worth knowing, because they explain why some languages allow certain overrides and forbid others. A subclass method is allowed to accept a broader range of input types than the parent promised (this is called being contravariant on parameters — think of it as “I’ll happily accept anything you throw at me, and maybe more”). A subclass method is allowed to return a narrower, more specific type than the parent promised (called being covariant on return types — “I’ll give you back something at least as specific as promised, maybe more precise”). Getting these backwards — demanding a narrower input or returning something broader than promised — is exactly the kind of signature-level mistake that breaks substitutability, and thankfully, it’s one of the few LSP mistakes most modern compilers will actually catch for you.

Almost every explanation of LSP eventually reaches the same famous example, and it’s famous for a good reason — it’s a small, honest trap that catches even experienced engineers. Mathematically, a square genuinely is a special kind of rectangle, one where all four sides happen to be equal. So it feels completely natural to write a Square class that extends a Rectangle class. That’s where the trouble quietly begins.

class Rectangle:
    def __init__(self, width, height):
        self.width = width
        self.height = height

    def set_width(self, value):
        self.width = value

    def set_height(self, value):
        self.height = value

    def area(self):
        return self.width * self.height


class Square(Rectangle):
    # A square forces both sides to stay equal
    def set_width(self, value):
        self.width = value
        self.height = value  # quietly changes height too!

    def set_height(self, value):
        self.width = value
        self.height = value

On its own, that code looks reasonable — even tidy. The trouble appears the moment some other piece of code, written only to understand “Rectangle,” gets handed a Square without knowing it:

def describe_area(shape):
    shape.set_width(4)
    shape.set_height(5)
    # A caller who only knows about Rectangle expects area == 20
    print("Area:", shape.area())

describe_area(Rectangle(0, 0))   # prints: Area: 20 — as expected
describe_area(Square(0, 0))      # prints: Area: 25 — not what anyone expected!

Nothing here crashes. No error message appears. The program keeps running happily, just with the wrong number quietly baked into it — which is exactly what makes LSP violations so dangerous. They rarely announce themselves; they just slowly produce results nobody trusts anymore.

The deeper lesson isn’t “never model a Square as a kind of Rectangle.” It’s that real-world “is-a” relationships and code “is-a” relationships aren’t automatically the same thing. A square is a rectangle in geometry class. In a codebase where Rectangle promises “width and height can be set independently,” a Square simply cannot honestly keep that promise — so it shouldn’t inherit from a class that makes it.

It’s also worth noticing what this example does not say. It doesn’t say inheritance is dangerous, or that squares and rectangles can never be related in code at all. It says that the specific promise “width and height are independent” is one that a Square, by its very geometric nature, is unable to honour — so that particular promise should never have been placed in a shared parent class both types inherit from. Recognising which promises a type can genuinely make, before writing a single line of inheritance, is the entire skill LSP is trying to teach.

The rectangle-square trap isn’t a one-off oddity — the same shape of mistake shows up constantly across completely different kinds of software, usually because a subclass was created purely because it “felt” related, without checking whether it could truly keep every promise.

It’s worth pausing on why this keeps happening even to careful, experienced engineers. Inheritance is genuinely tempting because it saves typing — reuse a class, override one or two methods, and move on. The trap is that this convenience is measured in the moment of writing the code, while the cost of a broken promise is paid much later, by a completely different engineer, in a completely different part of the codebase, who has no idea the shortcut was ever taken. That delay between cause and effect is exactly what makes LSP violations feel almost invisible until they cause a real, confusing bug in production.

class Bird:
    def fly(self):
        return "Soaring through the sky!"

class Penguin(Bird):
    def fly(self):
        raise NotImplementedError("Penguins can't fly!")

def send_bird_south(bird):
    # Written to trust every Bird can fly. Crashes the instant
    # someone passes a Penguin — a silent trap for whoever calls this later.
    print(bird.fly())

Notice the pattern repeating across every single example: the subclass either does less than promised, throws an error the parent never mentioned, or requires an extra condition the caller was never told about. Every one of those is, at its heart, the same broken contract described back in chapter five — it just wears a different costume each time.

LSP violations rarely announce themselves with a compiler error, so engineers learn to recognise a handful of warning signs instead — little code smells that almost always point back to a broken substitutability promise.

• Type-checking before calling a method — code that asks “is this actually a Penguin?” before deciding whether it’s safe to call a method, instead of just trusting the base type.
• Methods that throw “not supported” errors — a strong sign the subclass was forced to inherit something it was never truly able to do.
• Empty or do-nothing overrides — a method that exists only to satisfy the compiler, without doing anything meaningful.
• Overridden methods with unexpected side effects — like the Square example, where setting one value silently changes another.
• Comments warning “don’t use this subclass here” — one of the clearest possible signals that trust in the hierarchy has already broken down.

Automated tests can help too. A well-known technique is to write one shared set of tests against the base type’s promises, then run that exact same test suite against every single subclass. Any subclass that fails tests the base type passes has, by definition, violated LSP — no manual code review even required.

Code review is still worth its weight in gold here, because some static-analysis tools can flag obvious signature mismatches but very few can reliably catch a behavioural surprise on their own. A reviewer who simply asks, out loud, “if I swapped this new subclass into every place the base type is currently used, would anything break?” catches more real LSP problems than most automated tooling ever will. It’s a cheap question to ask, and it’s worth asking every time a new subclass is added to an existing hierarchy, not just when something has already gone wrong.

The good news is that LSP violations are almost always fixable, and usually the fix makes the whole design simpler and more honest, not more complicated. Here are the techniques engineers reach for most often, roughly in the order they’re usually tried:

class Bird:
    def eat(self):
        return "Pecking at some seeds."

class FlyingBird(Bird):
    def fly(self):
        return "Soaring through the sky!"

class Sparrow(FlyingBird):
    pass

class Penguin(Bird):
    def swim(self):
        return "Gliding through icy water."

# Now send_bird_south() only ever accepts FlyingBird —
# a Penguin can never be handed to it by mistake.

None of these fixes are free — splitting an abstraction means slightly more code to read, and composition sometimes means writing a little boilerplate to forward calls from one object to another. That’s a fair trade. A little extra structure paid upfront is almost always cheaper than the alternative: a hierarchy full of silent surprises that engineers learn to work around instead of trust, one defensive type-check at a time.

LSP rarely works alone — it leans on, and is leaned on by, the other four SOLID principles. Understanding these connections makes each principle easier to remember, because they start reinforcing each other instead of feeling like five separate rules to memorise.

A useful way to remember the relationship: SRP and ISP help you draw honest abstractions in the first place, and LSP is the rule that checks whether those abstractions are actually being respected once subclasses start appearing. OCP is the reward you get for getting all of this right — a codebase you can extend confidently instead of nervously.

A few failure modes show up over and over again the moment a team first tries to apply LSP seriously. Recognising them early is much cheaper than diagnosing them after they’ve caused a production bug.

Trusting the Compiler Too Much

Because signature rules are automatically checked, it’s easy to assume “my code compiles, so LSP must be fine.” As the Rectangle-Square example showed, behavioural violations sail straight past any compiler, completely unnoticed, every single time.

Modelling Real-World Categories Too Literally

Just because something is true in biology, geometry, or everyday language doesn’t mean it should become an inheritance relationship in code. A square being a rectangle, or a penguin being a bird, is true in the real world — but code hierarchies should be built around shared behaviour, not shared vocabulary.

Avoiding Composition Out of Habit

Some engineers reach for inheritance purely because it’s the tool they learned first, even in cases where composition would model the relationship far more honestly. It’s worth remembering that “Square has-a Rectangle-like calculation” is often a truer statement about the code than “Square is-a Rectangle” — and reaching for composition isn’t a lesser choice, it’s frequently the more accurate one.

Fixing Violations With More Type-Checks

A common but unhealthy patch is adding “if this is actually a Penguin, skip this part” checks scattered throughout the codebase. This doesn’t fix the violation — it just hides it, and every new subclass added later has to remember to add its own special-case check too.

A handful of questions come up almost every time a team first starts using LSP as a serious design tool. Getting straight answers on them early keeps the conversation focused on real design decisions rather than terminology arguments.

Does LSP only apply to inheritance?

Not strictly. LSP is really about subtyping — the promise that one type can stand in for another. Most of the time that relationship comes from class inheritance, but it can equally apply when a class implements an interface, or even in languages that don’t use classes at all. Wherever one piece of code promises to behave like another, LSP’s rules about honouring that promise still apply.

Can a tool or compiler catch every violation automatically?

No, and this trips up a lot of newcomers. Signature-level problems — wrong parameter types, missing methods — are usually caught instantly by the compiler. But behavioural problems, like a method quietly returning a different result than expected, require careful design, code review, and well-written tests. There is no button you can press that guarantees LSP compliance.

Is inheritance always the wrong tool?

Not at all — inheritance is a perfectly good tool when every subtype genuinely can honour every promise the parent type makes, without exception. The problem only shows up when a team reaches for inheritance purely because two things sound related in everyday language, without checking whether their behaviour truly lines up.

What’s the difference between LSP and simple polymorphism?

Polymorphism is the general ability for different types to be used through a common interface — it’s a feature most modern programming languages simply provide for free. LSP is a design discipline layered on top of that feature: it’s the promise that using polymorphism this way won’t quietly break your program’s correctness. You can have polymorphism without LSP; you just end up with polymorphism you can’t fully trust.

How strict should a team be about this in practice?

Treat LSP as a strong default, not an unbreakable law enforced at gunpoint. In small, low-stakes scripts, a minor violation might genuinely not matter. But in any codebase shared by more than one engineer, or expected to grow subclasses over time, taking a few extra minutes to check substitutability during design almost always pays for itself many times over.

Everything above collapses neatly into a handful of durable ideas — the ones worth carrying into any future project where inheritance and subtyping are on the table.