DEV Community


Liskov Substitution Principle

Igor Irianto
Bad puns, web development, creating stuff.
Updated on ・1 min read

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.

Discussion (0)