LSP Isn’t Theory—It’s How You Stop Inheritance Bugs in Interviews

The Liskov Substitution Principle (LSP) is simple and practical: if type S extends type T, you must be able to use S anywhere T is expected without breaking correctness. In other words, a subtype must preserve the behavior (contract) of its parent.

This isn't academic nitpicking—it's the rule that prevents a common and deceptively sneaky bug in interviews and code reviews: the Square–Rectangle problem.

The classic trap: Square inheriting Rectangle

At first glance, it makes sense: a square is a rectangle with equal sides, so why not subclass Rectangle? The problem shows up when Rectangle exposes mutating operations like setWidth and setHeight. A Rectangle lets you change one side independently; a Square doesn't. If your Square subclass overrides these methods to keep sides equal, substituting a Square where a Rectangle is expected can break client code that relies on independent width/height changes.

Example (pseudo-code):

class Rectangle {
  int width, height;
  void setWidth(int w) { width = w; }
  void setHeight(int h) { height = h; }
}

class Square extends Rectangle {
  void setWidth(int w) {
    width = w; height = w; // breaks Rectangle's contract
  }
  void setHeight(int h) {
    width = h; height = h;
  }
}

// Client code expecting Rectangle:
Rectangle r = new Square();
r.setWidth(5);
r.setHeight(10);
// Client expected width=5, height=10, but Square forces width=height

The client’s expectations (the parent contract) are violated by the subclass behavior. That’s an LSP violation.

Interview rule of thumb

When asked about inheritance or asked to design types in an interview, treat LSP as a go/no-go check:

• Ask: what invariants and behaviors does the parent type guarantee? (mutability, side effects, method semantics)
• If a candidate subtype cannot uphold those guarantees, it must not inherit.
• If inheritance would require overriding to change or restrict behaviors in ways that break clients, prefer composition or redesign.

Practical alternatives

• Use composition: a Square can hold a Rectangle (or a Dimensions object) and expose a clearer API.
• Make the parent immutable or provide a different abstraction (e.g., Shape with area/perimeter, or Separate Width/Height types).
• Introduce separate hierarchies: MutableRectangle vs ImmutableRectangle, or Rectangle and Square as different branches that don't extend one another.

Quick checklist for interviews (and code reviews)

• Does the subclass honor all public method contracts of the parent?
• Will client code relying on the parent’s behavior still work with the subclass?
• Are there methods in the parent that the subclass cannot implement without changing semantics?
• If the answer is no, prefer composition or redesign the abstraction.

Bottom line

LSP is not an abstract rule you can ignore in interviews—it's the practical guardrail that keeps inheritance from introducing subtle, correctness-breaking bugs. When a subclass cannot preserve the parent's contract, don’t force inheritance: redesign or compose instead.

#SOLID #SoftwareEngineering #SystemDesign