Liskov Substitution Principle
The Liskov Substitution Principle (LSP) states that when you substitute a parent object reference with an object of any of its subclasses, the program should not break.
If a thing looks like a duck and it quacks like a duck, then it better be a duck.
Suppose that your duck has a baby duck. The baby duckling also looks like a duck and quacks like a duck and it also... breathes fire. Whoopsie. That's not supposed to happen.
In this quack analogy, the duck is the parent class. It exhibits duck-like attributes. These duck-like attributes are parts of the duck contract (a duck contract sets up a certain expectation of what a duck class should be like). The duckling is the subclass. Being a descendent of a duck, you expect it to also exhibit duck-like attributes. However, this fire-breathing ability violates the contract because ducks don't breathe fire. This is a violation of the Liskov Substitution Principle.
The LSP doesn't prevent the subclasses from adding new methods. A babyDuck
class can have differing attributes like size = "small"
and color = "yellow"
while the parent class has attributes size = "medium"
and color = "brown"
. These differences won't violate the LSP because they fall within the user expectation. The subclasses don't need to return identical outputs as the parent, but they need to be consistent. A duck subclass with fireBreathing = true
attribute is not consistent because it is not the trait of a duck. It is a duck-dragon chimera.
At the heart of LSP, it's all about having consistent interfaces and following contracts.
Top comments (0)