Implementation Mechanism of Polymorphism-Java

Since polymorphism is one of the three essential characteristics of object-oriented (the other two are data abstraction and inheritance), why does C ++ not set the default method of method calling to dynamic binding, but should we mark it with the keyword virtual? Bruce Eckel mentioned in Thinking in C ++ that this is due to historical reasons. C ++ is developed from C, and C programmers are most concerned with performance issues, because dynamic binding has several more commands than static binding, the performance has declined. If dynamic binding is set to the default method call method, many C programmers may not accept it. Therefore, C ++ positions dynamic binding as optional and ensures that If you don't use it, you don't pay for it (Stroustrup ).
However, Java, as a brand new fully object-oriented language, does not have backward compatibility issues. At the same time, Java designers also think that polymorphism is the core of object-oriented, the object-oriented language should provide built-in support. Therefore, Java uses dynamic binding as the default method for method calls.
Next, let's take a closer look at how Java supports polymorphism. Like C ++, Java also has a data structure that stores the instance method address. In C ++, we call it VTable, the Method Table in java has many similarities:
1. They serve the same purpose and are also used to assist in dynamic binding of implementation methods.
2. It is also a class-level data structure. All objects of a class share a method table.
3. Search for a method in the data structure by offset.
4. Make sure that the offset of the methods inherited from the base class in all derived classes in the method table is the same as that of the method in the base class method table.
5. The method table can only store polymorphism methods (the instance method in Java and the vitual method in C ++ ).
However, in the final analysis, C ++ is a compilation language, while Java is more inclined to parse. Therefore, the above data structure generation and maintenance are different, as shown in:
1. In C ++, VTable and vptr are automatically generated by the compiler during the compilation phase. That is to say, before the C ++ program loads the memory. obj (. o) the file already contains information about these structures. The method table in Java is generated by JVM. Therefore, it is generated after compiling using the javac command. the class file does not contain information about the method table. A method table associated with the. class file will be dynamically generated for the. class file only when the JVM loads the. class file into the memory and placed in the JVM method area.
2. The index number of a method in C ++ in VTable is clearly known in the compilation phase and does not need to be dynamically known during the running process. The method in Java is only a symbol at the beginning, it is not a clear address. It is parsed into an offset in the method table only when the method is called for the first time. That is to say, only at this time, the instance method clearly knows the offset in the statement. Before that, you must go through a parsing process.
In addition, Java does not support multi-inheritance, so it will not be confused in this quagmire like C ++, but Java also introduces a new concept, that is, interfaces. The process of calling an instance method using an Interface is different from that of using a Class:
Public class Zoo
{
Public static void main (String [] args)
{
Pet p1 = new Dog ();
Pet p2 = new Dog ();
P1.say (); // parse it once first to get the offset and call the method.
P2.say (); // call

Cute c1 = new Dog ();
Cute c2 = new Dog ();
C1.cute (); // The interface is used to call the instance method. The method is parsed once first to obtain the offset and call the corresponding method.
C2.cute (); // although it has been resolved last time, you have to re-parse it once the same as the last time. Get the offset and call
}
}
Interface Cute
{
Public void cute ();
}
Class Pet
{
Public void say () {System. out. println ("Pet say ");}
}
Class Dog extends Pet implements Cute
{
Public void cute () {System. out. println ("Dog cute ");}
Public void say () {System. out. println ("Dog say ");}
}
Why is there such a difference? This is because the classes that implement the same interface do not guarantee that they all inherit from the same superclass, And the superclass also implement the same interfaces. Therefore, the methods declared by this interface cannot all be in the same position in the method table. For example, you can define the following classes:
Class Cat implements Cute
{
Public void cute () {System. out. println ("Cat cute ");}
}
Therefore, both Dog and Cat implement the Cute interface, so they can be called using the Cute interface, however, the location of method cute in the Dog method table cannot be ensured that the method is the same in the Cat method table. Therefore, for the interface call method, we had to re-Parse each time to obtain an accurate offset and then call it. This also leads to lower efficiency in calling methods using interfaces than in calling instance methods using classes. Of course, this is only relatively speaking. JVM will be optimized in implementation. We cannot say that it will not be used because of the low interface efficiency. On the contrary, it is due to the powerful role of interfaces in Object-Oriented functions, java advocates the use of interfaces, which should be noted.
Another point is that although java does not support multi-class inheritance, it can implement multiple interfaces, will the necessary conversions be performed in Java like the multi-inheritance of c ++? To solve this problem, we only need to think about the specific process of calling the two, and we can know that the Java interface method needs to be parsed before each call. Here, we will get the real offset, this is different from the offset obtained during compilation in C ++. Therefore, the so-called conversion is not required in Java.

Author "guiven"