Object-Oriented Design Law (4) -- liskov replacement law (LSP)

To use a function referenced by a base class (superclass), you must be able to use it without knowing the type of the object of a specific derived class (subclass.

[Function thar use referennces to base (Super) classes must be able to use objects

Of derived (sub) classes without knowing it]

Liskov replacement rules

1. Obviously, the liskov replacement rule (LSP) is derived from the "polymorphism" that I know well.

2. For example:

The method drawshape should work with any subclass of the sharp superclass (or, if sharp is a Java interface, this method can work with any class that implements the sharp interface)

However, we must be cautious when implementing child classes to ensure that we do not inadvertently violate the LSP.

3. If a function fails to satisfy the LSP, it may be because it explicitly references some or all sub-classes of the superclass. This function also violates OCP, because when we create a new subclass, we haveCode.

LSP example

1. Consider the following rectangle class:

2. What will happen to the square class now? Obviously, a square is a quadrilateral, so the square class should be derived from the rectangle class, right? Let's take a look!

3. You can see:

A. a square does not need to use both height and width as attributes, but in short it inherits from rectangle. Therefore, every square object will waste a little memory, but this is not a major problem.

B. The inherited setwidth () and setheight () methods are not really suitable for square because the height and width of a square are the same. Therefore, we need to override the setwidth () and setheight () methods. These simple methods that have to be rewritten may be an inappropriate method of inheritance and use.

3. The square class is as follows:

4. It looks pretty good. But let's test it!

5. TestProgramOutput:

6. It seems that we are against LSP!

7. Where is the problem? The programmer who compiled the testlsp () method made a reasonable assumption that the width of the rectangle should be changed to keep its height unchanged.

8. A problem occurs when a square object is passed to such a method. This obviously violates LSP.

9. The square and rectangle classes are consistent and legal. Although programmers make reasonable assumptions about the base class, the method they write will still lead to model design failure.

10. solutions cannot be viewed in isolation. They must be viewed based on the reasonable assumptions made by the design user.

11. A square in a mathematical sense may be a quadrilateral, but a square object is not a rectangle object, because the behavior of a square object is inconsistent with that of a rectangle object!

12. In terms of behavior, a square is not a rectangle! A square object and a rectangle object are not characteristic of polymorphism.

Summary

1. The liskov replacement law (LSP) clearly shows that all ISA relationships are behavior-related.

2. To keep the LSP (along with the open-closed Law), all subclasses must comply with the expected behavior of the client using the base class.

3. A subtype must not have more restrictions than the base type. It may be valid for the base type, but it may be because it violates one of the additional restrictions of the Child type, this violates LSP!

4. LSP ensures that a subclass can always be used where its base class can appear!