Liskov Substitution Principle
The Liskov Substitution Principle [1] (LSP) is applied to inheritance hierarchies. LSP specifies that classes should be designed such that client dependencies can be substituted with subclasses without the client “knowing”.
How to apply the Liskov Substitution Principle
To adhere to Liskov Substitution Principle, subclasses must function in the same way as their base classes. The specific functionality of the subclass may be different but must conform to the expected behavior of the base class. This means that, in order to be a true behavioral subtype, the subclass must implement the base class’s methods and properties. It also means the subclass must conform to the base class’s implied behavior.
A subclass behavior should never do less than its superclass. In other words, if the subtype does something that the client does not expect, such as throw an exception or imposes unexpected behavior, then the design in violation of the Liskov Substitution Principle.
Why is the LSP important?
Undefined behavior results from not adhering to the Liskov Substitution Principle. Undefined behavior can be a real “Gotcha” as it can seem to work okay during development and then unexpectedly bug out in production. This kind of issue can cause a team to spend weeks debugging something that is very difficult to duplicate.
Reference
Liskov Substitution Principle, https://en.wikipedia.org/wiki/Liskov_substitution_principle
[…] [L] Because the strategize subclasses are implementing an interface, they satisfy the Liskov Substitution Principle. […]
[…] [L] The Factory Method Pattern employs subclasses, implementing the base class’s methods and properties. The subclasses conform to the base class’s implied behavior. By this we can see that the Factory Method Pattern satisfies the Liskov Substitution Principle. […]