JAVA: One article to clarify polymorphism

Many people always like, or mistakenly understand, the polymorphism of Java is very complex, the most common error is called "Method polymorphism", they will give a similar example to prove that "polymorphism refers to the polymorphism of the method":

Copy Code

Enginner and mechanic are the subclass of employee, and the constructor parameters are monthly salary
Employee a=new Enginner (100);
Employee b=new Mechanic (100);

Getannualsalary is the Employee class method for calculating and returning an annual salary
System.out.println (A.getannualsalary ());//output 1500,enginner annual salary of 15 times times the monthly salary
System.out.println (B.getannualsalary ());//output 1300,mechanic annual salary of 13 times times the monthly salary
Copy Code

From the results, A, b are the Employee class object variables, but for a call Getannualsalary () returned is thesalary, the B call Getannualsalary () but returned to thesalary, It seems that the so-called "method polymorphism", after all, the same class of object variables called the same method, the internal implementation of the way is different. Based on this idea, even some people extend polymorphism to a wider, more complex situation, such as the following, even generics are counted in polymorphic:

　　

So, polymorphism really is there so many things? Is it true that as long as the method name is the same, and the parameter or internal implementation is different, it should be considered polymorphic? No no no, this is purely nonsense, there are polymorphic and only one case in Java: The object variable is polymorphic. This understanding is crucial, and it can be said that this is the point to remember for polymorphic concepts. But why, in the above example, the same method is called for A and B, will it have different effects? Note that this is the knowledge category of the method invocation, but it just happens to be related to polymorphism. Let's take a look at the knowledge of polymorphism and method invocation.

The polymorphism in Java is brought about by the inheritance mechanism, because there are inheritance mechanisms, so there is polymorphism. In a nutshell, the cause of polymorphism is that a parent class object variable is allowed to reference a subclass object in Java (as for why we would say later):

Son is a subclass of father.
Father variable=new Son (); Variable is a father class object variable, but the object it actually references is the son class object
Because the parent class object variable can refer to the subclass object, when we see a Class A object variable, we cannot contended that the object it refers to is a Class A object, it may also refer to Class B object, Class C object ... As long as it refers to the object that is a class A subclass object on the line. This is polymorphic: the type of the object that the object variable actually refers to is not necessarily the type of the object variable declaration.

But the simple polymorphism is not used, I have made the Employee class object variable a refer to a Enginner object, and then, even if I rewrite getannualsalary in Enginner to return 15 pay, Do you still return a 12 pay when you call Getannualsalary? (Suppose Getannualsalary returns 12*salary in the Employee Class) What's the point?

So in fact, the existence of polymorphic, must have the method call when the dynamic binding support only makes sense. The dynamic binding of a call to a method is that the virtual opportunity invokes the method that best matches the actual type referenced by the variable.

For example, the getannualsalary of the employee class returns aSalary,enginner class that overrides the method to return tothe salary, when the following conditions occur:

Employee a=new Enginner (100);
int annualsalary=a.getannualsalary ();
The virtual opportunity first determines what type of object the variable a refers to (the actual type is Enginner) and then checks to see if its actual type overrides the method (this example Enginner overrides the Getannualsalary method in the employee). If it is, call the method in its actual type (this example also calls the Getannualsalary in the Enginner class that returns 15*salary), otherwise call the method in the type of a declaration (that is, employee).

With polymorphic + dynamic binding, we can quickly achieve some effects. For example, write an abstract class list, declare a GET method to get the specified element in the list, declare a set method to set the specified element in the list, and then implement a non-abstract subclass LinkedList, using the list structure to store lists internally, and then implement a ArrayList, An array structure is used internally to store the list. In this way, we can write code using polymorphic + dynamic binding:

List a=new ArrayList ();
Oldvalue=a.get (i);
A.set (I,newvalue);
If we want to use a list that is well-supported for random access, we can write like this, even if a refers to a ArrayList object, and if one day we want to use a list with good support for dynamic additions or deletions, just

List a=new ArrayList ();
Switch

List a=new LinkedList ();
And the rest of the code does not need to be changed. With the method's dynamic binding, calls to get and set are automatically made to the method calls in the LinkedList class. This makes it a simple matter to change the actual storage structure of the list.

In addition, polymorphic + dynamic binding can also be used to simplify the code when "focus on common methods only". What do you mean? For example, Enginner and mechanic have their own different, new methods based on the employee class. But when we're counting staff salaries, we don't want to focus on what's unique to them, but we want to pay attention to the same annual salary as employee. Then I can put each enginner, mechanic into an employee array, and then iterate through the array, call getannualsalary and output for each element, without having to iterate over the Enginner-gen-number group. Again to the mechanic hit the number group to traverse again.

Of course, there are many other uses for polymorphic + dynamic binding, especially in the Java Collection Class application, which is not in detail here.

If dynamic binding solves the problem of polymorphic method invocation, then static binding is to implement the (method) overloading mechanism quickly. The so-called overloaded mechanism means that in Java, the name of a method is allowed to be the same as another method that already exists, as long as the number or type of arguments for the two methods is different. This method overload is the case where multiple methods have the same name and different parameters. The "method" described here can also be a constructor, so this mechanism is called: overloading.

To implement overloading, you have to decide which method to call, based on the parameters given when calling the method. But when is it going to be OK? In Java, this confirmation step is determined when the compiler translates the source code into bytecode, that is, the compiler javac to determine which method is actually called based on the number and type of arguments given by the method invocation, thus implementing overloading. Because it is determined at compile time, this binding process is static binding.

However, it is important to note that static binding is not really a "binding", it is actually a filter. What do you mean? For example, suppose the getannualsalary of the employee class has a version with parameters: Getannualsalary (double bonusrate), that is, given a "bonus ratio" to calculate the annual salary, So when you call Getannualsalary () on an Employee class object variable A, the compiler first makes a static binding, or filtering, to determine that the method call here cannot be a version with parameters, but it may be the method of the Employee class, It is also possible that this method of the Enginner or mechanic class, after being statically bound, leaves three possibilities, which are then determined by the virtual machine at run time by dynamic binding to determine the method that is actually called.

In fact, overloading can also be done for the virtual machine to do things, but through the compiler's static binding to filter out a portion of the method, you can make the virtual machine to determine the actual call method to reduce some work, only focus on the possible methods of dynamic binding. So static binding is for fast implementation of overloads.

There is certainly a lot of detail about polymorphism, method invocation, such as a method x (int) and an overloaded method X (double), which can be called either x (int) or x (double) in the Call of X (3). Why does overloading not allow only return types to be different? However, these details are not what this article wants to discuss, this article is basically the above-mentioned sketchy content.

In general, the most important point in learning Java polymorphism is to understand that polymorphism refers to the polymorphism of the object variable, not to complicate the concept of polymorphism. As for the so-called "method polymorphism", is actually the method call static binding (filtering) and dynamic binding.

Need more study material Dabigatran: 537775426, Ali Java senior architect free Live to explain the knowledge points, share knowledge, many years work experience combing and summary, with everyone comprehensive, scientific to establish their own technical system and technical knowledge!

JAVA: One article to clarify polymorphism