Liskov Substitution Principle in LLD - System Design Guide

Problem Statement

When a subclass cannot fully replace its parent class without causing errors or unexpected behavior, the system becomes fragile and hard to maintain. This leads to bugs when code using the parent class expects certain behavior that the subclass violates.

Solution

Ensure that subclasses can stand in for their parent classes without changing the correctness of the program. This means subclasses must honor the contracts of the parent class, including method behavior and expected outcomes, so any code using the parent class can safely use the subclass.

Architecture

ParentClass

+ operation()

→SubClass

↓

Client Code

calls op()

→Uses Parent

This diagram shows client code using a parent class interface. The subclass inherits and overrides methods but must behave consistently so the client code works correctly with either.

Trade-offs

✓ Pros

→

Improves code reliability by preventing unexpected behavior from subclasses.

→

Makes code easier to maintain and extend by enforcing consistent interfaces.

→

Supports polymorphism, allowing flexible and reusable code.

✗ Cons

→

Requires careful design of class hierarchies and method contracts.

→

May limit subclass implementations if strict adherence is enforced.

→

Can increase upfront design time to ensure proper substitutability.

Use when designing class hierarchies that will be extended or reused, especially in large or evolving codebases where polymorphism is important.

When classes are simple and unlikely to be subclassed or when quick prototyping is more important than long-term maintainability.

Real World Examples

Amazon

Amazon ensures that different payment method classes can replace a generic payment interface without breaking order processing workflows.

Netflix

Netflix uses this principle to allow different streaming quality strategies to replace a base streaming class without affecting playback logic.

Uber

Uber applies this principle so various ride types can substitute a common ride interface, ensuring consistent fare calculation and booking.

Code Example

The before code violates Liskov because Ostrich cannot fly but inherits fly(), causing errors. The after code fixes this by changing the method to move(), which all birds can do differently, ensuring subclasses can replace the parent without breaking behavior.

LLD

### Before applying Liskov Substitution Principle (violating it):

class Bird:
    def fly(self):
        print("Flying")

class Ostrich(Bird):
    def fly(self):
        raise Exception("Ostriches can't fly")


def make_bird_fly(bird: Bird):
    bird.fly()

ostrich = Ostrich()
make_bird_fly(ostrich)  # Raises Exception unexpectedly


### After applying Liskov Substitution Principle (correct):

class Bird:
    def move(self):
        print("Moving")

class FlyingBird(Bird):
    def move(self):
        print("Flying")

class Ostrich(Bird):
    def move(self):
        print("Running")


def make_bird_move(bird: Bird):
    bird.move()

ostrich = Ostrich()
make_bird_move(ostrich)  # Prints "Running" safely

flying_bird = FlyingBird()
make_bird_move(flying_bird)  # Prints "Flying" safely

Alternatives

Interface Segregation Principle

Focuses on splitting interfaces into smaller, client-specific ones rather than ensuring subclass substitutability.

Use when: When clients only need parts of an interface and large interfaces cause unnecessary dependencies.

Dependency Inversion Principle

Focuses on depending on abstractions rather than concrete classes, complementing Liskov but addressing different concerns.

Use when: When you want to decouple high-level modules from low-level implementations.

Summary

Liskov Substitution Principle ensures subclasses can replace parent classes without breaking the program.

It enforces consistent behavior so client code works with any subclass transparently.

Following it improves code reliability, maintainability, and supports polymorphism.

Practice

1.

What does the Liskov Substitution Principle (LSP) primarily ensure in system design?

easy

A. Child classes can replace parent classes without affecting correctness

B. Parent classes must never be extended

C. Child classes should have fewer methods than parent classes

D. Parent classes should depend on child classes

Solution

1. Step 1: Understand LSP definition

   LSP states that objects of a child class should be replaceable with objects of the parent class without breaking the program.

2. Step 2: Analyze options against LSP

   Only Child classes can replace parent classes without affecting correctness correctly describes this principle. Other options contradict LSP or are unrelated.

3. Final Answer:

   Child classes can replace parent classes without affecting correctness -> Option A

4. Quick Check:

   Liskov Substitution Principle = Child replaces Parent [OK]

Hint: LSP means child works anywhere parent is expected [OK]

Common Mistakes:

• Thinking LSP forbids inheritance
• Confusing LSP with interface segregation
• Believing child classes can change parent behavior arbitrarily

2.

Which of the following class declarations follows the Liskov Substitution Principle?

class Bird {
  fly() {}
}

class Penguin extends Bird {
  fly() {
    throw new Error('Cannot fly');
  }
}

easy

A. Yes, because Penguin is a Bird

B. No, because Penguin breaks expected behavior of Bird

C. Yes, because Penguin overrides fly method

D. No, because Bird should not have fly method

Solution

1. Step 1: Analyze Penguin's fly method

   Penguin throws an error on fly(), but Bird expects fly() to work normally.

2. Step 2: Check LSP compliance

   Since Penguin cannot be used where Bird is expected (fly method fails), it violates LSP.

3. Final Answer:

   No, because Penguin breaks expected behavior of Bird -> Option B

4. Quick Check:

   Child must not break parent behavior = No [OK]

Hint: Child must not break parent's expected methods [OK]

Common Mistakes:

• Ignoring method behavior changes in child
• Assuming inheritance alone guarantees LSP
• Thinking overriding with error is allowed

3.

Consider the following code snippet. What will be the output?

class Vehicle {
  start() { return 'Vehicle started'; }
}

class Car extends Vehicle {
  start() { return 'Car started'; }
}

function startVehicle(v) {
  return v.start();
}

const myCar = new Car();
console.log(startVehicle(myCar));

medium

A. 'Vehicle started'

B. Error: start is not a function

C. 'Car started'

D. undefined

Solution

1. Step 1: Understand method overriding

   Car overrides start() method to return 'Car started'.

2. Step 2: Trace function call

   startVehicle(myCar) calls myCar.start(), which returns 'Car started'.

3. Final Answer:

   'Car started' -> Option C

4. Quick Check:

   Overridden method returns child's message [OK]

Hint: Child method overrides parent, so child's output shows [OK]

Common Mistakes:

• Expecting parent method output instead of child's
• Confusing method names or forgetting override
• Assuming error due to polymorphism

4.

Identify the violation of Liskov Substitution Principle in the code below and select the fix.

class Rectangle {
  setWidth(w) { this.width = w; }
  setHeight(h) { this.height = h; }
  area() { return this.width * this.height; }
}

class Square extends Rectangle {
  setWidth(w) {
    this.width = w;
    this.height = w;
  }
  setHeight(h) {
    this.width = h;
    this.height = h;
  }
}

medium

A. Use separate classes without inheritance for Square and Rectangle

B. Square should not override setWidth and setHeight

C. Square should only override area() method

D. No violation, code is correct

Solution

1. Step 1: Identify LSP violation

   Square changes behavior of setWidth and setHeight, breaking Rectangle's expectations.

2. Step 2: Choose fix

   To follow LSP, Square and Rectangle should not be in inheritance relation if behaviors differ fundamentally.

3. Final Answer:

   Use separate classes without inheritance for Square and Rectangle -> Option A

4. Quick Check:

   Different behavior means no inheritance [OK]

Hint: If child changes parent's method meaning, avoid inheritance [OK]

Common Mistakes:

• Ignoring behavioral changes in overridden methods
• Trying to fix by only overriding area()
• Assuming inheritance always fits shapes

5.

You are designing a payment system with a base class PaymentMethod and subclasses CreditCard and Bitcoin. The base class has a method processPayment(amount) that returns a success message. However, Bitcoin payments require additional confirmation steps and may fail differently. How should you design these classes to follow the Liskov Substitution Principle?

hard

A. Make processPayment abstract and force subclasses to implement their own versions ignoring base behavior

B. Make Bitcoin inherit PaymentMethod and override processPayment to throw errors on failure

C. Remove inheritance and implement separate interfaces for each payment type

D. Keep Bitcoin and CreditCard as subclasses but ensure processPayment behaves consistently and returns success/failure uniformly

Solution

1. Step 1: Understand LSP in payment context

   Subclasses must behave so they can replace base class without breaking client code.

2. Step 2: Design consistent behavior

   Bitcoin and CreditCard should implement processPayment so it returns success/failure in a consistent way, hiding internal differences.

3. Final Answer:

   Keep Bitcoin and CreditCard as subclasses but ensure processPayment behaves consistently and returns success/failure uniformly -> Option D

4. Quick Check:

   Consistent behavior across subclasses = LSP compliance [OK]

Hint: Subclasses must behave consistently to replace parent safely [OK]

Common Mistakes:

• Throwing errors breaking expected method contracts
• Ignoring different failure modes without abstraction
• Removing inheritance unnecessarily