3. Liskov Substitution Principle
Last updated
Was this helpful?
Last updated
Was this helpful?
Was this helpful?
calling code should be able to use an instance of a base class or an instance of a derived class without knowing it, or having to do anything special.
It says that if the X class inherits from the Y class, then Y's entire black-box test suit should also pass for X.
Example
A square is not a rectangle
As long as an interface doesn't change, the clients don't care if you change the implementation
if code starts to look like if (shape is Square) ... else if (shape is Rectangle) ..., it can be a “code smell”
Why?
reduce complexity in calling code so that it can work generically on any class or subclass without additional conditional code.
https://blog.caplin.com/2010/09/30/a-junit-trick-for-ensuring-solid-design/
Sometimes you do want to have different behaviour to the super class
It was original stated by
Even the author says, the idea of substitutability was informal and was not evening in formal definition (https://dl.acm.org/doi/10.1145/197320.197383, https://www.youtube.com/watch?v=-Z-17h3jG0A)
https://stackify.com/solid-design-liskov-substitution-principle/
https://dzone.com/articles/solid-principles-liskov-substitution-principle
https://medium.com/hackernoon/the-liskov-substitution-principle-and-why-you-might-want-to-enforce-it-6f5bbb05c06d
https://reflectoring.io/lsp-explained/