Коротка відповідь: це цілком можливо, але Java не робить цього.
Ось код, який ілюструє поточний стан справ на Яві:
Файл Base.java:
package sp.trial;
public class Base {
static void printValue() {
System.out.println(" Called static Base method.");
}
void nonStatPrintValue() {
System.out.println(" Called non-static Base method.");
}
void nonLocalIndirectStatMethod() {
System.out.println(" Non-static calls overridden(?) static:");
System.out.print(" ");
this.printValue();
}
}
Файл Child.java:
package sp.trial;
public class Child extends Base {
static void printValue() {
System.out.println(" Called static Child method.");
}
void nonStatPrintValue() {
System.out.println(" Called non-static Child method.");
}
void localIndirectStatMethod() {
System.out.println(" Non-static calls own static:");
System.out.print(" ");
printValue();
}
public static void main(String[] args) {
System.out.println("Object: static type Base; runtime type Child:");
Base base = new Child();
base.printValue();
base.nonStatPrintValue();
System.out.println("Object: static type Child; runtime type Child:");
Child child = new Child();
child.printValue();
child.nonStatPrintValue();
System.out.println("Class: Child static call:");
Child.printValue();
System.out.println("Class: Base static call:");
Base.printValue();
System.out.println("Object: static/runtime type Child -- call static from non-static method of Child:");
child.localIndirectStatMethod();
System.out.println("Object: static/runtime type Child -- call static from non-static method of Base:");
child.nonLocalIndirectStatMethod();
}
}
Якщо ви запустили це (я це робив на Mac, з Eclipse, використовуючи Java 1.6), ви отримаєте:
Object: static type Base; runtime type Child.
Called static Base method.
Called non-static Child method.
Object: static type Child; runtime type Child.
Called static Child method.
Called non-static Child method.
Class: Child static call.
Called static Child method.
Class: Base static call.
Called static Base method.
Object: static/runtime type Child -- call static from non-static method of Child.
Non-static calls own static.
Called static Child method.
Object: static/runtime type Child -- call static from non-static method of Base.
Non-static calls overridden(?) static.
Called static Base method.
Тут єдиний випадок, який може стати несподіванкою (і стосовно якого йдеться про це), є першим випадком:
"Тип запуску не використовується для визначення того, які статичні методи викликаються, навіть коли вони викликаються об'єктом об'єкта ( obj.staticMethod())."
і останній випадок:
"При виклику статичного методу всередині об'єктного методу класу обраний статичний метод - це той, який доступний із самого класу, а не з класу, що визначає тип об'єкта часу виконання."
Виклик з екземпляром об'єкта
Статичний виклик вирішується під час компіляції, тоді як нестатичний виклик методу вирішується під час виконання. Зауважте, що хоча статичні методи успадковуються (від батьків), вони не перекриваються (від дитини). Це може стати сюрпризом, якщо ви очікували іншого.
Виклик всередині об'єктного методу
Виклики методу об'єкта вирішуються за допомогою типу запуску, але статичні ( класові ) виклики методу вирішуються за допомогою типу компіляції (оголошеного).
Зміна правил
Щоб змінити ці правила, щоб останній виклик у наведеному прикладі Child.printValue()статичним викликам повинен був надавати тип під час виконання, а не компілятор, який розв'язує виклик під час компіляції із заявленим класом об'єкта (або контекст). Тоді статичні виклики можуть використовувати (динамічний) тип ієрархії для вирішення виклику, як і сьогодні.
Це легко зробити (якщо ми змінили Java: -O), і це зовсім нерозумно, проте, це має деякі цікаві міркування.
Основна думка полягає в тому, що нам потрібно вирішити, які статичні виклики методу повинні це робити.
На даний момент у Java є ця "химерність" у мові, згідно з якою obj.staticMethod()дзвінки замінюються ObjectClass.staticMethod()дзвінками (як правило, з попередженням). [ Примітка: ObjectClass це тип часу компіляції obj.] Це були б хороші кандидати для переопределення таким чином, приймаючи тип часу виконання obj.
Якби ми це зробили, це ускладнило б читання органам методів: статичні виклики в батьківському класі потенційно можуть бути динамічно "перенаправлені". Щоб уникнути цього, нам доведеться викликати статичний метод з назвою класу - і це робить виклики більш очевидно вирішеними за допомогою ієрархії типу компіляції (як зараз).
Інші способи виклику статичного методу є більш складними: this.staticMethod()повинні означати те саме obj.staticMethod(), що, наприклад, з типом виконання часу this. Однак це може спричинити деякі головні болі в існуючих програмах, які викликають (мабуть, локальні) статичні методи без декору (що, можливо, еквівалентно this.method()).
То як же бути з неприхильними дзвінками staticMethod()? Я пропоную зробити це так само, як сьогодні, і використовувати контекст місцевого класу, щоб вирішити, що робити. Інакше настане велика плутанина. Звичайно, це означає, що method()це означало б, this.method()якщо це methodбув нестатичний метод, а ThisClass.method()якби methodстатичний метод. Це ще одне джерело плутанини.
Інші міркування
Якщо ми змінили цю поведінку (і зробили статичні виклики потенційно динамічно нелокальним), ми, ймовірно , захочете переглянути зміст final, privateа protectedтакож відбіркові на staticметодах класу. Ми б тоді всі повинні звикнути до того , що private staticі public finalметоди не перевизначений, і тому може бути безпечно вирішене під час компіляції, і є «безпечними» , щоб читати місцеві посилання.