Wrap Up (2)

The Liskov Substitution Principle (LSP) is critical in ensuring that your class hierarchies are robust, flexible, and maintainable. By following LSP, you ensure that derived classes can seamlessly replace their base classes without introducing unexpected behavior or breaking the system.

Why is LSP Important?

• Prevents Fragile Code: LSP helps avoid situations where subclass behavior violates the expectations set by the parent class. This prevents fragile code where one small change in a subclass can break the system.
• Improves Flexibility: By designing classes that can be substituted without breaking the parent contract, you create flexible systems that allow for easy extension and maintenance.
• Ensures Correctness: When LSP is followed, the correctness of the program is maintained, as subclasses respect the rules and behaviors of their parent classes, ensuring reliable, predictable results.
• Promotes Code Reusability: LSP makes it easier to reuse base classes and create new subclasses without having to modify existing code, keeping your system scalable and reusable.

Numeric trace you must be able to recite

The classic Square-extends-Rectangle failure is not abstract — run the numbers:

// client written against Rectangle
r.setWidth(5);
r.setHeight(4);
assert r.area() == 20;   // 5 × 4

// when r is a Square that forces sides equal:
// setWidth(5)  → side = 5
// setHeight(4) → side = 4 (overwrites width too)
// area()       → 4 × 4 = 16  ≠ 20  → assertion fails

Area is 16, not 20. That single numeric failure is the whole of LSP: a Square is not a behavioural subtype of a mutable Rectangle, even though it is a geometric special case. Rename nothing — restructure the hierarchy (common Shape with area(), or composition).

LSP Takeaways

Principle	Smell	Fix	When it hurts
Liskov Substitution Principle	Subclass overrides methods that weaken preconditions, strengthen postconditions, or throw unexpected exceptions; instanceof checks are needed to handle special cases; numeric postconditions fail (area 16 ≠ 20).	Respect the contract: preconditions can only stay the same or weaken; postconditions can only stay the same or strengthen. Prefer composition when "is-a" is not honest. Split the base to only what every subtype can honour.	Not every domain relationship fits inheritance; forcing an LSP-compliant hierarchy can produce awkward abstractions. A thin common base (or no inheritance) is often cleaner than a "complete" tree.

When applying LSP / inheritance hurts

• False is-a. Mathematical subset (Square ⊂ Rectangle) ≠ behavioural subtype of a mutable Rectangle API.
• Instanceof special-casing. If callers must branch on subtype, the abstraction already failed — do not paper over it with more branches.
• Throwing "not supported". Refusing a base method is refusing the base promise; split the capability off the base type.

LSP → Design Patterns

These patterns help you honor substitution without fragile inheritance:

• Strategy — Lets behaviors vary without subclassing the context, sidestepping the "is-a" trap entirely.
• Composition over Inheritance — The default fix for an LSP violation: model "has-a" or "uses-a" instead of "is-a."
• Template Method — Useful when the skeleton is stable and only specific steps vary; the base class defines the contract and subclasses fill hooks without breaking it.

Follow-Up Drills

1. Classic case: a Square extends Rectangle. Walk setWidth(5); setHeight(4); and show why area is 16 not 20. How would you model squares and rectangles without violating LSP?
2. You have a Bird base class with a fly() method. A Penguin subclass cannot fly. Is the hierarchy wrong, or is the method wrong? Defend your answer.
3. Find an instanceof check in a codebase. Is it covering up an LSP violation or a genuine type dispatch?
4. Write a behavioral contract test that encodes the base type's promise (e.g. account.withdraw(x) never drives the balance below zero, area() equals width×height after independent setters) and run the same test suite against every subtype. A subtype that fails the base's test is an LSP violation the compiler cannot catch — this is how you turn "honors the contract" into something executable.

Before You Continue

LSP is where object-oriented design becomes honest. If your inheritance tree requires callers to know special cases, the abstraction is leaking. Fix it with composition or a sharper contract before moving on to ISP and DIP.

I just read a lesson on **Wrap Up (2)** (OO & Low-Level Design) and want to truly understand it. Explain Wrap Up (2) from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Teach me **Wrap Up (2)** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Quiz me on **Wrap Up (2)** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Help me remember **Wrap Up (2)** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.