Home › OO & Low-Level Design › SOLID Principles

Introduction to the Liskov Substitution Principle

The Liskov Substitution Principle (LSP) is an important concept in object-oriented design. It states:

"Objects of a superclass should be replaceable with objects of a subclass without affecting the correctness of the program."

This principle means that a subclass should behave in a way that it can substitute for its parent class without causing issues in the system. If a subclass breaks the behavior expected from the parent class, it violates LSP.

Problem Example: Car and Electric Car

Let’s take a simple example of a Car class to see where the problem arises when LSP is violated.

Imagine you have a Car class with methods to start, stop, and refuel the car.
Now, you decide to extend this class and create an ElectricCar class. This class should also start and stop like a regular car, but since it doesn’t use fuel, the refuel() method becomes problematic.
Instead ElectricCar class has recharge() method.

java

public class Car {
    public void start() {
        System.out.println("Car is starting");
    }

    public void stop() {
        System.out.println("Car is stopping");
    }

    public void refuel() {
        System.out.println("Car is refueling");
    }
}

public class ElectricCar extends Car {
    @Override
    public void refuel() {
        // Electric cars don't use fuel, so what do we do here?
        throw new UnsupportedOperationException("Electric cars don't need refueling");
    }

      public void reCharge() {
        System.out.println("Car is recharging");
    }
}

In this example, the ElectricCar class overrides the refuel() method from the Car class, but it cannot implement the functionality properly because electric cars don’t use fuel. This leads to an issue where calling the refuel() method on an ElectricCar will break the program by throwing an exception.

Why Previous Example Violates LSP?

According to the Liskov Substitution Principle, we should be able to replace an instance of Car with an instance of ElectricCar without breaking the functionality. However, let’s see what happens when we create objects of these classes and call their methods.

java

public class Main {
    public static void main(String[] args) {
        // Creating an instance of Car
        Car myCar = new Car();
        myCar.start();
        myCar.refuel(); // This works fine as expected for a regular car
        myCar.stop();

        // Creating an instance of ElectricCar
        Car myElectricCar = new ElectricCar(); // We are treating ElectricCar as a Car
        myElectricCar.start();
        
        // Here's the problem:
        // When we call the refuel() method, it throws an exception
        // because ElectricCar doesn't need refueling
        myElectricCar.refuel();  // This will throw an UnsupportedOperationException
        
        myElectricCar.stop(); // This works, but refuel() breaks the program
    }
}

In this example:

We create an instance of the Car class and everything works as expected.
We then create an instance of the ElectricCar class, but treat it as a Car (since ElectricCar is a subclass of Car).
When we call the refuel() method on the ElectricCar object, it throws an UnsupportedOperationException because electric cars don’t use fuel. This breaks the program.

The Actual Reason Behind the Violation of LSP

This behavior violates the Liskov Substitution Principle because:

We cannot seamlessly substitute an instance of the Car class with an instance of ElectricCar without breaking the program.
The ElectricCar class cannot fulfill the contract of the Car class, specifically regarding the refuel() method.

In this lesson, we’ve seen how trying to treat ElectricCar as a Car leads to issues when the expected behavior of the parent class isn’t respected by the subclass. In the next lesson, we will explore how to properly redesign the system to adhere to LSP.

🤖 Don't fully get this? Learn it with Claude

Stuck on Introduction to the Liskov Substitution Principle? Open Claude, copy a block below, and it'll teach you this exact concept — visually and interactively.

🎨 Explain it visually

Build the mental picture, not memorization.

I just read a lesson on **Introduction to the Liskov Substitution Principle** (OO & Low-Level Design) and want to truly understand it. Explain Introduction to the Liskov Substitution Principle from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

🤔 Walk me through it (interactive)

Socratic — adapts to where you're stuck.

Teach me **Introduction to the Liskov Substitution Principle** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

🧪 Quiz me & fix my gaps

Active recall exposes what you missed.

Quiz me on **Introduction to the Liskov Substitution Principle** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

🧠 Make it stick

Intuition + hook + flashcards for long-term memory.

Help me remember **Introduction to the Liskov Substitution Principle** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

📝 My notes

← Final Thoughts on the OpenClosed P Break The Hierarchy for Adhering t →