Quick version that will save your weekend. The Liskov Substitution Principle says a subtype must behave like the base type when the base type is expected. This is about behavior not matching method names. If a subclass breaks contracts or surprises client code then you have an LSP problem and probably less fun debugging on Friday night.

Core rules to actually remember

• Do not make preconditions stricter in a subtype
• Do not make postconditions weaker in a subtype
• Preserve the invariants the base type promised

Those three rules are the meat and potatoes of LSP. They map to polymorphism and subtyping in OOP and are a key part of SOLID thinking and clean architecture. If you ignore them you will get code smells and confused teammates.

Classic pitfall that everyone copies into legacy code

The rectangle square problem is the poster child. A Rectangle lets you set width and height independently. A Square inherits and forces them to match. Client code that assumes independent setters gets wrong results and mysterious failures.

class Rectangle
  width
  height
  setWidth(w)
  setHeight(h)

class Square extends Rectangle
  setWidth(w)
    setHeight(w)
  setHeight(h)
    setWidth(h)

That is a textbook violation of LSP and of common sense. The fix is not always clever inheritance. Often composition is the diplomatic solution.

Design moves that stop the bleeding

• Prefer composition over inheritance when behavior differs
• Program to interfaces that express the contract not the implementation
• Write behavioral tests that verify substitutability rather than method names

Unit tests that treat a list of subtype instances as a list of base type instances are boring but effective. Make tests that exercise the contract. If you can describe expected outcomes in simple assertions then you have something close to a behavioral contract.

Quick checklist before you inherit

• Does the subtype accept the same inputs under the same conditions
• Does it guarantee the same outcomes
• Does it keep the same invariants as the base type

If the answer to any is no then reach for composition or a new abstraction. Following LSP gives fewer runtime surprises, clearer contracts, and code that behaves nicely under extension. In other words you will spend less time apologizing to your future self.