For inheritance, there may be an argument that inheritance can only improve the functions of the original base class? If the answer is yes, the derived type is exactly the same type as the underlying class because it has exactly the same interface. The result is that we are perfectly able to replace an object of the derived class with an object of the underlying class! Think of it as a "pure substitution". In a sense, this is an ideal way of inheriting. At this point, we usually think of an "equivalence" relationship between the underlying class and the derived class--because we can justifiably say that "a circle is a geometrical shape." One way to test inheritance is to see if you can get them into this "equivalence" relationship and see if it makes sense.
But in many cases, we have to add a new interface element for the derived type. So not only has the interface been extended, but also a new type has been created. This new type can still be substituted for the underlying type, but this substitution is not perfect because the new function cannot be accessed in the underlying class. We call it a "similar" relationship; the new type has an interface of the old type, but it also contains other functions, so it cannot be said that they are completely equivalent. For example, let's consider the condition of the refrigerator. Suppose our rooms are equipped with a variety of controllers for refrigeration, that is, we have the necessary "interface" to control refrigeration. Now assuming the machine is out of service, we replace it with a new cold and hot air conditioner that can be used both in winter and in summer. Cold, hot air conditioner "similar" refrigerator, but can do more things. Since our rooms are only equipped to control refrigeration, they are limited to dealing with the refrigeration part of the new machine. The interface of the new machine has been extended, but the existing system does not know anything except the original interface.
When we recognize the difference between equivalence and similarity, we will be more sure when we replace it. Although most of the time "pure substitution" is sufficient, you will find that in some cases there is still a compelling reason to add new functionality on the basis of derived classes. I believe we have a good idea of how to do this before we get through the discussion of these two situations.