SOLID — Liskov Substitution Principle — Coding notes

WHY does LSP exist?

The L in SOLID comes from Barbara Liskov (1987). Her formal statement:

WHAT exactly must a subclass preserve? (The contract)

A subclass overriding a method must respect the behavioural contract, not just the method signature. Three rules:

WHY those directions? (Derivation from the caller's view)

Intuition Derive the rules from scratch

Imagine a caller written against the base. The caller only knows the base contract. It will:

send inputs that satisfy pre_base
rely on outputs that satisfy post_base

Precondition: The caller promises to send inputs in pre_base. If the subclass demanded more (a stronger precondition), the caller — knowing nothing of it — would send a now-illegal input → crash. So the subclass must accept everything pre_base allows. Hence pre_base ⇒ pre_sub. ✅

Postcondition: The caller relies on post_base. If the subclass guaranteed less, the caller's later code breaks. So the subclass must keep at least post_base. Hence post_sub ⇒ post_base. ✅

Notice the arrows point opposite ways — preconditions widen (contravariant), postconditions narrow (covariant). This isn't arbitrary; it falls straight out of "don't surprise a caller who only knows the base."

Figure — SOLID — Liskov Substitution Principle

HOW to spot a violation — the classic Rectangle/Square

Worked example The Square is NOT a Rectangle (in code)

Math says a square is a rectangle. Code disagrees.

class Rectangle {
  protected int w, h;
  void setWidth(int w)  { this.w = w; }
  void setHeight(int h) { this.h = h; }
  int area() { return w * h; }
}
 
class Square extends Rectangle {
  void setWidth(int w)  { this.w = w; this.h = w; } // keeps it square
  void setHeight(int h) { this.h = h; this.w = h; }
}

Now a caller written against Rectangle:

void test(Rectangle r) {
  r.setWidth(5);
  r.setHeight(4);
  assert r.area() == 20;   // invariant the caller relies on
}

Why this step? The caller proved a property: "set 5×4 → area 20." This is a φ(x) for Rectangle.

Pass a Square: setHeight(4) also resets width → area becomes $4\times4=16$ , not 20. The provable property fails → LSP violated.

Which rule broke? The base's invariant "width and height are independent" was silently broken. Postcondition of setHeight was weakened (it no longer guarantees width is unchanged).

Worked example A correct refactor (favour composition / shared abstraction)

Don't make Square extends Rectangle. Instead:

interface Shape { int area(); }
class Rectangle implements Shape {
  private final int w, h;
  Rectangle(int w, int h){ this.w=w; this.h=h; }
  public int area(){ return w*h; }
}
class Square implements Shape {
  private final int s;
  Square(int s){ this.s=s; }
  public int area(){ return s*s; }
}

Why this step? By making both immutable and sharing only area() (a contract both honour fully), there's no setWidth/setHeight whose contract a Square can violate. Substitutability is restored.

Worked example The Bird / Penguin trap

class Bird { void fly(){ /*...*/ } }
class Penguin extends Bird {
  void fly(){ throw new UnsupportedOperationException(); }
}

Why this is a violation: any code doing bird.fly() is correct for Bird but throws for Penguin — a new exception not in the base contract (rule 3). Fix: split the hierarchy: Bird and FlyingBird extends Bird. Penguin extends Bird, not FlyingBird. Now no caller of FlyingBird.fly() can ever get a Penguin.

Common mistakes (Steel-manned)

Flashcards

LSP in one sentence

Subtypes must be substitutable for their base type without breaking program correctness.

Who formulated LSP

Barbara Liskov (1987).

Can a subclass strengthen a precondition?

No — preconditions may only be weakened/widened (must accept ≥ the base's inputs).

Can a subclass weaken a postcondition?

No — postconditions may only be strengthened/narrowed (must guarantee ≥ the base's promises).

Why are preconditions contravariant and postconditions covariant?

Because a caller who only knows the base sends base-legal inputs and relies on base-promised outputs; widening inputs / narrowing outputs never surprises that caller.

Why does Square extends Rectangle violate LSP

setWidth/setHeight on a mutable Square change the other dimension, breaking the invariant that width and height are independent that a Rectangle caller relies on.

Why is Penguin extends Bird (with fly()) an LSP violation

Penguin.fly() throws an exception not in Bird's contract (rule 3: no new exception types).

A common fix when a subtype can't honor a method

Restructure the hierarchy / split interfaces so that subtype is never substitutable where the capability is required.

LSP enables which feature to actually work

Polymorphism — coding once against a base type and trusting all subtypes.

Recall Feynman: explain to a 12-year-old

Imagine a job posting that says "We need someone who can drive a car." You hire whoever shows up, trusting they can drive. LSP says: if you call someone a "Driver," they'd better actually drive — you shouldn't get a person who, when you hand them keys, screams "I can't drive!" or who can only turn left. A "subclass" is like a more specific kind of Driver (a taxi driver, a race driver). Each one must be able to do everything a normal Driver can do, or your plans fall apart. If a "Penguin" claims to be a "Bird that flies" but can't fly, don't call it that — give it a different label so nobody hands it a sky-job.

Connections

SOLID — Single Responsibility Principle — both keep classes honest about their role.
SOLID — Open Closed Principle — LSP makes safe polymorphic extension possible.
SOLID — Interface Segregation Principle — splitting interfaces is the usual fix for LSP violations (Penguin).
SOLID — Dependency Inversion Principle — depending on abstractions only works if subtypes are substitutable.
Design by Contract — Meyer's pre/post/invariant framework that LSP formalises.
Polymorphism — the feature LSP exists to protect.

Concept Map

Hinglish (regional understanding)

Intuition Hinglish mein samjho

LSP ka matlab simple hai: agar tumhara code kisi base class ke against likha gaya hai, to tum usme koi bhi subclass ka object daalo, program toot-na nahi chahiye. Subclass ek vaada hai — "main woh sab kar sakta hoon jo mera parent kar sakta tha, usi tarah." Agar subclass chupke se behaviour badal de (jaise exception throw kar de ya alag result de), to caller ko har jagah if-else lagana padega, aur tabhi to inheritance ka poora fayda khatam ho jaata hai.

Sabse famous example: Square extends Rectangle. Maths me square ek rectangle hota hai, par code me dhokha hai. Rectangle me setWidth(5) aur setHeight(4) karoge to area 20 aana chahiye. Lekin Square me width set karne se height bhi change ho jaati hai, to area 16 aa jaata hai. Caller ne jo property maani thi (20) woh fail ho gayi — yahi LSP violation hai. Solution: dono ko immutable banao ya ek common Shape interface use karo jisme sirf area() ho.

Do golden rules yaad rakho — Wide In, Narrow Out (WINO). Subclass ko inputs me zyada accept karna chahiye (preconditions weaken kar sakte ho), aur outputs me kam se kam utna dena chahiye jitna base deta tha (postconditions strengthen kar sakte ho). Ulta karoge — input restrict kiya ya output kam diya — to base ke caller ko surprise milega aur crash hoga.

Yeh principle important kyun hai? Kyunki yeh polymorphism ko bachata hai. Polymorphism ka pura sapna yeh hai ki ek baar base ke against code likho aur sab subtypes ke saath chal jaaye. LSP woh guarantee deta hai. Penguin wala example bhi yaad rakho: agar Penguin Bird se extend karke fly() me exception phenke, to galat hai — hierarchy todo: FlyingBird alag banao, Penguin sirf Bird se extend kare.

SOLID — Liskov Substitution Principle

WHY does LSP exist?

WHAT exactly must a subclass preserve? (The contract)

WHY those directions? (Derivation from the caller's view)

HOW to spot a violation — the classic Rectangle/Square

Common mistakes (Steel-manned)

Flashcards

Connections

Concept Map

Hinglish (regional understanding)

Go deeper — visual, from zero

Test yourself — Design Principles

Connections