1. The method definition in overloaded Java includes both the method header and the method body, where the method header is used to uniquely (identify) a method, and the method body represents the function of the method. The method header specifically contains modifiers, return types, method names, and four parts of the argument list. Modifiers do not affect the definition of the method, ignore first, focus on the latter three parts. As everyone knows, a class cannot define two method headers in exactly the same way, otherwise, when the method is invoked, exactly which is executed. So, you have to have a flag to distinguish two different methods. The most intuitive is the method name. However, the method name is not the only flag that distinguishes two methods, and we have a list of parameters. That is, a class can define two methods with the same name, as long as they have a different argument list, a tall name, called method overload. The JVM can automatically identify which method to call based on the difference in the argument list. The argument list behaves differently: The number of arguments is the same, or the number of parameters is the same, but the corresponding position is of a different type. In the second case, for example:
void set (int a, String b);
void Set (String b, int a);
These two methods are actually just two parameters that fall off the position, but they can also be distinguished by the JVM. In practice, however, you should avoid doing so, because there is no egg to use and can easily cause confusion. Method names and parameter lists are called method signatures, and in Java, a flag that uniquely identifies a method is the method signature. As long as the two methods have different method signatures, they are identified by the JVM as two different methods. The compiler will only pass through a method that can be uniquely positioned by the JVM. The method signature does not include a return value, that is, a method in a class that cannot define two methods with the same signature but with a different return type. Is it different to differentiate two methods by return value? Theoretically it is possible, at least the compiler can be identified. The problem is that the JVM doesn't recognize the return type, so the compiler won't let you. The root cause is the JVM, which is the runtime's positioning of the method. Suppose we define two methods that have the same method signature, but the return type is different:
String get () {return "a";}
int get () {return 3;}
Now call one of these:
int c = Get ();
Look, we've already indicated the return type. Ah, why not the difference. Notice the order in which the statement is executed, by first invoking the method to obtain the result, and then assigning the result to the variable. This means that when the method is invoked, the JVM simply doesn't care what the return type is, and gets the results first. As for why the JVM is so designed to be temporarily ignored (I don't know, I don't understand), as long as I know, because the JVM does not recognize the return type, it causes two methods that define two signatures but different return types cannot be compiled.
2. Overlay coverage occurs when inheriting, specifically defining a method that already exists in a parent class in a subclass. The "existing" criterion is the method signature, excluding the return type. In fact, in two classes to define a signature and even the return type are the same way nothing strange, after all, not the same class. However, when two classes have an inheritance relationship, this is called overlay. What's the difference? Yes, when subclasses inherit the parent class, the variables and methods of the parent class are also valid in the subclass (regardless of access rights), and the code that corresponds to the parent class also appears in the subclass (syntactically, a method that can directly invoke the parent class). As a result, the problem encountered by overloading is again encountered in inheritance: Now there are two methods in the subclass and the parent class that have the same signature, so which is the call. Overloaded scenarios (in the same class), the signatures of two methods are not allowed to be identical. Because the JVM is really indistinguishable, but in an inherited scenario, it allows subclasses to define a method that is the same as the parent class, because the JVM has a way of distinguishing between the two methods, which are not really in the same class. But it is dangerous to do so: there are two different methods in the subclass that can be invoked. So when the call occurs, which one is the call? We all know that Java method calls are late-bound, that is, the runtime chooses the object based on its actual type, rather than the object's declaring type. So, in this case, the call is actually a subclass of the method. In other words, the duplicate method of the parent class is hidden-it cannot be invoked through subclasses. Within subclasses, the method of invoking the same name of the parent class can only be distinguished by super, whereas in other classes, by the object of the subclass, the method of the subclass is always invoked. So when you accidentally overwrite a method of the parent class and call this method of the parent class in your code, the result of the program may not be what you want it to run. So, we need to @override this annotation to identify a method that overrides the parent class. If the subclass method does not overwrite the parent class method, adding the annotation will cause an error when compiling. However, except for special cases, no one adds this annotation for each method in writing code, just to try to test the method of accidentally overwriting the parent class. Moreover, even if the method of overriding the parent class does not add this annotation, the compilation can still pass-@Override is not mandatory. So, this annotation is more of a normative nature, used to remind yourself or others. There are several rules to be covered in syntax:
(1) When you try to overwrite the static method of the parent class, the subclass's method must also be static. If you set a non-static method in the subclass, and the parent class has exactly one static method with the same signature, then the compile will be an error;
(2) Similarly, when overriding a non-static method of a parent class, the subclass's method must also be non-static. These two rules are summed up as follows: cannot cross overlay.
(3) The final modification of the method can not be covered, final is to do this
(4) When you do want to overwrite a method of the parent class, the method signature in the subclass must be exactly the same as the parent class method. Otherwise, if the overlay fails, the overriding purpose is not reached; (5) When overriding the method, the return value of the subclass method must be the parent class method return value type or its subclass, that is, the coverage also makes the return value;
(6) When overriding a method, the throwing exception of a subclass method must be a parent class method that throws an exception type or its subclasses. This sentence, after my experiment, is so run: The subclass method either throws an exception or throws an exception that is not related to the parent class exception, but cannot throw the parent class of the parent class exception. Otherwise, the compiler complains. Give an example later.
(7) I encountered a phenomenon, did not expect to have this operation. Examples are as follows:
public class Parent {public
void printall () {
print ();
}
public void print () {
System.out.println ("parent");
}
public class Child extends Parent {public
void print () {
System.out.println (' child ');
}
public static void Main (string[] args) {
printall ();
}
}
What the results of the execution will make. Print "Parent" or "child". Anyway, I was a prick at first. I thought I was going to print "parent," The result prints "child", that is, the subclass calls method one of the parent class, and the method calls method two of the parent class, and the subclass just overwrites method two with method three, and then the method three is called in the subclass. Around a circle, and finally back to the subclass of the override method.
3. Hide the variables or methods that have the same name as the parent class in the hidden subclass, so you can call only the variables and methods of subclasses by subclasses, which is hidden. Obviously, covering is a special case of concealment. Why do you say that? Because subclasses are forced to convert to a parent class, they can access the hidden variables and methods of the parent class, but the method includes only static methods, not the instance method. Variable parts, static and non-static can be overwritten.
