What is the Liskov Substitution Principle?
Learn the Liskov Substitution Principle (LSP) with the Square/Rectangle example, safe overrides, and Java code for interview prep.
Expected Interview Answer
The Liskov Substitution Principle (LSP) states that objects of a subclass must be substitutable for objects of the base class without altering the correctness of the program.
Formulated by Barbara Liskov, it means a subtype must honor the behavioral contract of its supertype: it cannot strengthen preconditions, weaken postconditions, or throw new exceptions the caller does not expect. A classic violation is a Square extending Rectangle and overriding setWidth to also change height, breaking any code that assumed width and height vary independently. LSP is the "L" in SOLID and exists to keep polymorphism safe — if substitution can silently break callers, inheritance was modeled incorrectly.
- Keeps polymorphic code predictable and safe
- Prevents subtle bugs from unsafe inheritance
- Forces correct is-a modeling over convenience
- Enables reliable unit testing against base types
AI Mentor Explanation
If a team’s selection policy says "any listed opening batter can walk out first," then every player on that list must actually be able to face the new ball without the team’s scoring plan collapsing. If a specialist middle-order batter is slipped onto the opener list and gets out first ball to swing bowling every time, the substitution breaks the plan even though the team sheet looks valid. LSP says a substitute must behave like the role it is filling, not just carry the label.
Step-by-Step Explanation
Step 1
Identify the base contract
Document the preconditions, postconditions, and invariants the base type promises callers.
Step 2
Check subtype behavior
Verify the subclass never demands more from callers or delivers less than the base type promised.
Step 3
Watch for behavioral overrides
Flag overrides that change side effects, throw new exceptions, or alter invariants silently.
Step 4
Prefer composition when unsafe
If the subtype cannot honor the contract, model the relationship with composition instead of inheritance.
What Interviewer Expects
- A precise statement of substitutability, not just "subclasses should work like the parent"
- The classic Square/Rectangle counterexample or an equivalent
- Understanding of pre/postcondition and invariant rules
- Recognition that LSP violations often mean the inheritance hierarchy is wrong
Common Mistakes
- Confusing LSP with simple polymorphism
- Missing that overridden methods can violate contracts even without compiler errors
- Not knowing the Square/Rectangle example
- Suggesting inheritance fixes what composition should handle
Best Answer (HR Friendly)
“The Liskov Substitution Principle says that a subclass should be usable anywhere its parent class is expected, without breaking the program. If swapping in a subclass changes behavior in a surprising way, the inheritance relationship was modeled incorrectly, and that is a sign to redesign it, often using composition instead.”
Code Example
class Rectangle {
protected double width, height;
void setWidth(double w) { this.width = w; }
void setHeight(double h) { this.height = h; }
double area() { return width * height; }
}
class Square extends Rectangle {
@Override
void setWidth(double w) { this.width = w; this.height = w; } // violates LSP
@Override
void setHeight(double h) { this.width = h; this.height = h; } // violates LSP
}
// Caller code that breaks when Square substitutes Rectangle
void resize(Rectangle r) {
r.setWidth(5);
r.setHeight(4);
assert r.area() == 20; // fails for Square, passes for Rectangle
}Follow-up Questions
- How does the Square/Rectangle problem illustrate an LSP violation?
- How would you redesign Square and Rectangle using composition instead?
- How does LSP relate to design by contract?
- Can you give an LSP violation involving exceptions thrown by an override?
MCQ Practice
1. The Liskov Substitution Principle primarily concerns?
LSP is about subtypes being safely substitutable for their base types without breaking correctness.
2. Which is a classic example of an LSP violation?
Square coupling width and height when set breaks the independent-dimension contract Rectangle callers expect.
3. An LSP-safe override may?
A subtype may weaken postconditions (promise more) or keep preconditions equal or weaker, never stricter.
Flash Cards
What does LSP stand for? — Liskov Substitution Principle — subtypes must be substitutable for their base types.
Classic LSP counterexample? — Square extending Rectangle and coupling width/height when either is set.
What can a valid override NOT do? — Strengthen preconditions, weaken postconditions, or throw new unexpected exceptions.
What often fixes an LSP violation? — Replacing inheritance with composition when the "is-a" relationship does not hold behaviorally.