Liskov Substitution Principle

The Liskov Substitution Principle (LSP) states that objects of a superclass should be replaceable with objects of its subclasses without breaking the application. In other words, derived classes must be substitutable for their base classes.

This principle was introduced by Barbara Liskov in 1987 and is a fundamental concept in object-oriented design.

Understanding the Principle

The Liskov Substitution Principle ensures that:

• Subclasses must honor the contract of their base class
• Subclasses should not weaken preconditions (requirements before a method runs)
• Subclasses should not strengthen postconditions (guarantees after a method runs)
• Subclasses should not throw new exceptions that the base class doesn’t throw

In simple terms: If it looks like a duck and quacks like a duck, it should behave like a duck!

The Duck Test

The Liskov Substitution Principle is often explained using the “duck test”: if something looks like a duck, walks like a duck, and quacks like a duck, then it should behave like a duck in all contexts. Subclasses should be indistinguishable from their base class when used in the same way.

Example 1: Rectangle and Square Problem

This is a classic example that demonstrates LSP violation. Let’s see why a Square should NOT inherit from Rectangle.

Violating LSP (Bad Approach)

LSP Violation

Why this violates LSP:

• Code that works with Rectangle breaks when given a Square
• Square changes the behavior of set_width() and set_height()
• The contract is broken: setting width should only change width, not height

This is a classic LSP violation - the Square class doesn’t honor Rectangle’s contract!

Following LSP (Good Approach)

Why this follows LSP:

• Both Rectangle and Square honor the Shape contract
• They can be used interchangeably where Shape is expected
• No unexpected behavior changes

---

Example 2: Payment Processing System

Consider a payment processing system where different payment methods need to be processed. Let’s see how LSP violations can cause real-world problems.

Violating LSP (Bad Approach)

Why this violates LSP:

• Code expecting PaymentProcessor breaks with CryptocurrencyProcessor
• refund() should always work, but crypto version throws exception
• The contract is broken: refunds should be possible for all payment types

Following LSP (Good Approach)

Why this follows LSP:

• Each class honors its specific contract
• CryptocurrencyProcessor doesn’t promise refunds it can’t deliver
• Type system prevents using non-refundable processors where refunds are needed
• No unexpected behavior or exceptions

---

Common LSP Violations to Avoid

Common Mistakes

These are the most common ways developers violate LSP. Watch out for these patterns in your code!

1. Throwing New Exceptions

2. Returning Incompatible Types

3. Weakening Preconditions

4. Strengthening Postconditions

---

Benefits of Following LSP

Why LSP Matters

Following LSP ensures:

1. Polymorphism Works Correctly - Subclasses can be used anywhere base class is expected
2. Fewer Bugs - No unexpected behavior when substituting subclasses
3. Better Design - Forces you to think about contracts and behavior
4. Easier Testing - Can test base class behavior and trust subclasses
5. Code Reusability - Functions written for base class work with all subclasses

Key Takeaways

Remember

• Subclasses must honor the contract - They should behave like their base class
• Don’t weaken preconditions - Subclasses should accept at least what base class accepts
• Don’t strengthen postconditions - Subclasses shouldn’t promise more than base class
• Don’t throw new exceptions - Subclasses shouldn’t introduce new exception types
• Use interfaces wisely - If a subclass can’t honor the contract, use a different interface
• Test substitutability - If you can’t substitute a subclass, the design is wrong

Remember: The Liskov Substitution Principle ensures that inheritance is used correctly and polymorphism works as expected! 🎯