The LSP principle, also known as the Richter replacement principle (Liskov Substitution Principle), is a more accurate definition:
Function ' s that ues point or references tobase classes must is able to use objects of derived classes without knowing it.
All references to base classes must be transparently used with their subclass objects
When using the LSP principle, it is necessary to be able to use its subclass object transparently wherever the parent class can appear, and no errors or exceptions will be generated if the child class is replaced with subclasses, but the child class may not be able to adapt to the parent class where the subclass appears.
It is important to use the parent class or interface when calling other classes in the class, and if the parent class or interface cannot be used, the design of the class has violated the LSP principle.
Downcast is unsafe downward transition is unsafe
When overloading, when a subclass extends beyond the scope of the input parameter type of the parent class, the subclass's method of passing to the caller's child class instead of the parent class is not executed.
The precondition of a method in a subclass must be the same or looser than the predecessor condition of the method being overridden in the superclass.
When a subclass inherits from a parent class, either overried or overload, its return value is less than or equal to the parent class return value, and the input parameter can be expanded when override implements the parent class method. Subclasses do not override the method of the parent class, the sub-class method is executed will cause confusion of business logic, so in the project to adopt the LSP principle should try to avoid the personality of the subclass.
-
Liskov Substitution Principle
Programming Principles--LSP