Можем ли мы переопределить статические методы? Почему выход так? [Дубликат]

Переопределение метода стало возможным благодаря динамической диспетчеризации , что означает, что объявленный тип объекта не определяет его поведение, а скорее его тип времени выполнения:

Animal lassie = new Dog();
lassie.speak(); // outputs "woof!"
Animal kermit = new Frog();
kermit.speak(); // outputs "ribbit!"

Несмотря на то, что оба lassie и kermit объявлены как объекты типа Animal, их поведение (метод .speak()) изменяется, потому что динамическая диспетчеризация будет только связывать вызов метода .speak() с реализация во время выполнения - не во время компиляции.

Теперь, вот где ключевое слово static начинает иметь смысл: слово «статический» является антонимом для «динамического». Поэтому причина, по которой вы не можете переопределить статические методы, заключается в том, что динамические диспетчеризации для статических элементов нет, потому что статическое буквально означает «не динамический». Если они отправлены динамически (и, следовательно, могут быть переопределены), ключевое слово static просто больше не имеет смысла.

В Java (и многих языках ООП, но я не могу говорить за всех, а некоторые вообще не имеют статичности), все методы имеют фиксированную подпись - параметры и типы. В виртуальном методе подразумевается первый параметр: ссылка на сам объект и при вызове внутри объекта, компилятор автоматически добавляет this.

Нет никакой разницы для статических методов - они все еще имеют фиксированную подпись. Однако, объявив метод static, вы прямо заявили, что компилятор не должен включать параметр подразумеваемого объекта в начале этой подписи. Поэтому любой другой код, который вызывает это, должен не должен пытаться помещать ссылку на объект в стеке . Если это так, то выполнение метода не будет работать, поскольку параметры будут не в том месте, которые сдвинуты на один - в стеке.

Из-за этой разницы между ними; виртуальные методы всегда имеют ссылку на объект контекста (т. е. this), поэтому можно ссылаться на что-либо внутри кучи, принадлежащей этому экземпляру объекта. Но со статическими методами, поскольку эта ссылка не передана, этот метод не может получить доступ к каким-либо объектным переменным и методам, поскольку контекст неизвестен.

Если вы хотите, чтобы Java изменила определение так, чтобы контекст объекта пройденный для каждого метода, статический или виртуальный, тогда у вас по существу будут только виртуальные методы.

Как кто-то спросил в комментарии к op - какова ваша причина и цель для желания этой функции?

Я не знаю Ruby много, как это было упомянуто OP, Я провел некоторое исследование. Я вижу, что в классах Ruby действительно особый вид объекта, и можно создавать (даже динамически) новые методы. Классы - это объекты полного класса в Ruby, они не находятся на Java. Это то, что вам нужно будет принять при работе с Java (или C #). Это не динамические языки, хотя C # добавляет некоторые формы динамических. На самом деле Ruby не имеет «статических» методов, насколько я мог найти - в этом случае это методы для объекта singleton class. Затем вы можете переопределить этот синглтон с новым классом, а методы в предыдущем объекте класса вызовут те, которые определены в новом классе (правильно?). Поэтому, если вы вызвали метод в контексте исходного класса, он все равно выполнил бы только исходную статику, но вызов метода в производном классе вызовет методы либо из родительского, либо подкласса. Интересно, и я вижу в этом какую-то ценность. Требуется другой шаблон мысли.

Поскольку вы работаете на Java, вам нужно будет приспособиться к этому. Почему они это сделали? Ну, возможно, чтобы улучшить производительность в то время на основе технологии и понимания, которые были доступны. Компьютерные языки постоянно развиваются. Вернитесь достаточно далеко, и нет такой вещи, как ООП. В будущем появятся другие новые идеи.

EDIT: Еще один комментарий. Теперь, когда я вижу различия и как сам разработчик Java / C #, я могу понять, почему ответы, которые вы получаете от разработчиков Java, могут сбивать с толку, если вы исходите с такого языка, как Ruby. Методы Java static не совпадают с методами Ruby class. Разработчикам Java будет трудно понять это, так же как и те, кто работает в основном с языком Ruby / Smalltalk. Я вижу, как это также будет очень смущать тем фактом, что Java также использует метод класса, как другой способ говорить о статических методах, но этот же термин используется по-разному Ruby. Java не имеет методов класса стиля Ruby (извините); Ruby не имеет статических методов стиля Java, которые на самом деле являются просто старыми процедурными функциями стиля, как показано на C.

Кстати - спасибо за вопрос! Я узнал что-то новое для меня сегодня о методах класса (стиль Ruby).

Отменяя, вы достигаете динамического полиморфизма. Когда вы говорите об переопределении статических методов, слова, которые вы пытаетесь использовать, противоречивы.

Статические слова - время компиляции, переопределение используется для динамического полиморфизма. Оба они противоположны по своей природе и поэтому не могут использоваться вместе.

Динамическое полиморфное поведение возникает, когда программист использует объект и получает доступ к методу экземпляра. JRE будет отображать различные методы экземпляра разных классов в зависимости от того, какой тип объекта вы используете.

Когда вы говорите, что переопределяете статические методы, статические методы, к которым мы будем обращаться, используя имя класса, которое будет связано с компиляцией времени, поэтому во время работы с статическими методами нет концепции связывания методов. Таким образом, термин «переопределяющий» статические методы сам по себе не имеет никакого значения.

Примечание: даже если вы обращаетесь к методу класса с объектом, все еще java-компилятор достаточно интеллектуальный, чтобы найти его и будет делать статическая связь.

В общем случае не имеет смысла позволять «переопределять» статические методы, поскольку не было бы хорошего способа определить, какой вызов вызывать во время выполнения. Взяв пример Employee, если мы вызываем RegularEmployee.getBonusMultiplier () - какой метод должен быть выполнен?

В случае Java можно представить себе определение языка, где можно «переопределить» статическую методы, если они вызываются через экземпляр объекта. Однако все это будет заключаться в повторной реализации обычных методов класса, добавляя избыточность к языку, не добавляя при этом никакой пользы.

Статические методы рассматриваются как глобальные JVM, они вообще не связаны с экземпляром объекта.

Это может быть концептуально возможно, если вы могли бы вызвать статические методы из объектов класса (например, на таких языках, как Smalltalk), но это не так на Java.

EDIT

Вы можете перегрузить статический метод, это нормально. Но вы не можете переопределить статический метод, потому что класс не является первоклассным объектом. Вы можете использовать отражение, чтобы получить класс объекта во время выполнения, но объект, который вы получаете, не параллелен иерархии классов.

class MyClass { ... }
class MySubClass extends MyClass { ... }

MyClass obj1 = new MyClass();
MySubClass obj2 = new MySubClass();

ob2 instanceof MyClass --> true

Class clazz1 = obj1.getClass();
Class clazz2 = obj2.getClass();

clazz2 instanceof clazz1 --> false

Вы можете размышлять над классами, но он останавливается там. Вы не вызываете статический метод, используя clazz1.staticMethod(), но используя MyClass.staticMethod(). Статический метод не привязан к объекту и, следовательно, не существует понятия this или super в статическом методе. Статический метод - глобальная функция; как следствие, также нет понятия полиморфизма, и поэтому переопределение метода не имеет смысла.

Но это возможно, если MyClass был объектом во время выполнения, на котором вы вызываете метод, как в Smalltalk (или, может быть, JRuby, как один комментарий, но я ничего не знаю о JRuby).

О да ... еще одна вещь. Вы можете вызвать статический метод через объект obj1.staticMethod(), но это действительно синтаксический сахар для MyClass.staticMethod(), и его следует избегать. Обычно это вызывает предупреждение в современной среде IDE. Я не знаю, почему они когда-либо допускали этот ярлык.

На самом деле мы ошибались. Несмотря на то, что Java по умолчанию не позволяет переопределять статические методы, если вы тщательно изучаете документацию классов класса и метода в Java, вы все равно можете найти способ эмуляции статических методов, переопределяющих следующие методы:

import java.lang.reflect.InvocationTargetException;
import java.math.BigDecimal;

class RegularEmployee {

    private BigDecimal salary = BigDecimal.ONE;

    public void setSalary(BigDecimal salary) {
        this.salary = salary;
    }
    public static BigDecimal getBonusMultiplier() {
        return new BigDecimal(".02");
    }
    public BigDecimal calculateBonus() {
        return salary.multiply(this.getBonusMultiplier());
    }
    public BigDecimal calculateOverridenBonus() {
        try {
            // System.out.println(this.getClass().getDeclaredMethod(
            // "getBonusMultiplier").toString());
            try {
                return salary.multiply((BigDecimal) this.getClass()
                    .getDeclaredMethod("getBonusMultiplier").invoke(this));
            } catch (IllegalAccessException e) {
                e.printStackTrace();
            } catch (IllegalArgumentException e) {
                e.printStackTrace();
            } catch (InvocationTargetException e) {
                e.printStackTrace();
            }
        } catch (NoSuchMethodException e) {
            e.printStackTrace();
        } catch (SecurityException e) {
            e.printStackTrace();
        }
        return null;
    }
    // ... presumably lots of other code ...
}

final class SpecialEmployee extends RegularEmployee {

    public static BigDecimal getBonusMultiplier() {
        return new BigDecimal(".03");
    }
}

public class StaticTestCoolMain {

    static public void main(String[] args) {
        RegularEmployee Alan = new RegularEmployee();
        System.out.println(Alan.calculateBonus());
        System.out.println(Alan.calculateOverridenBonus());
        SpecialEmployee Bob = new SpecialEmployee();
        System.out.println(Bob.calculateBonus());
        System.out.println(Bob.calculateOverridenBonus());
    }
}

Результат:

0.02
0.02
0.02
0.03

, чего мы пытались достичь:)

Даже если мы объявим третью переменную Carl как RegularEmployee и назначим ей экземпляр SpecialEmployee, мы будем все еще имеют вызов метода RegularEmployee в первом случае и вызов метода SpecialEmployee во втором случае

RegularEmployee Carl = new SpecialEmployee();

System.out.println(Carl.calculateBonus());
System.out.println(Carl.calculateOverridenBonus());

просто посмотрите на консоль вывода:

0.02
0.03

;)

Следующий код показывает, что это возможно:

class OverridenStaticMeth {   

static void printValue() {   
System.out.println("Overriden Meth");   
}   

}   

public class OverrideStaticMeth extends OverridenStaticMeth {   

static void printValue() {   
System.out.println("Overriding Meth");   
}   

public static void main(String[] args) {   
OverridenStaticMeth osm = new OverrideStaticMeth();   
osm.printValue();   

System.out.println("now, from main");
printValue();

}   

} 

Простое решение: используйте экземпляр singleton. Это позволит переопределить и наследовать.

В моей системе у меня есть класс SingletonsRegistry, который возвращает экземпляр для переданного класса. Если экземпляр не найден, он создается.

Класс языка Haxe:

package rflib.common.utils;
import haxe.ds.ObjectMap;



class SingletonsRegistry
{
  public static var instances:Map<Class<Dynamic>, Dynamic>;

  static function __init__()
  {
    StaticsInitializer.addCallback(SingletonsRegistry, function()
    {
      instances = null;
    });

  } 

  public static function getInstance(cls:Class<Dynamic>, ?args:Array<Dynamic>)
  {
    if (instances == null) {
      instances = untyped new ObjectMap<Dynamic, Dynamic>();      
    }

    if (!instances.exists(cls)) 
    {
      if (args == null) args = [];
      instances.set(cls, Type.createInstance(cls, args));
    }

    return instances.get(cls);
  }


  public static function validate(inst:Dynamic, cls:Class<Dynamic>)
  {
    if (instances == null) return;

    var inst2 = instances[cls];
    if (inst2 != null && inst != inst2) throw "Can\'t create multiple instances of " + Type.getClassName(cls) + " - it's singleton!";
  }

}

Статический метод, переменный, блочный или вложенный класс относится ко всему классу, а не к объекту.

Метод в Java используется для отображения поведения объекта / класса. Здесь, поскольку метод статичен (т. Е. Статический метод используется для представления поведения только класса). Изменение / переопределение поведения всего класса нарушит явление одного из фундаментальных элементов объектно-ориентированного программирования, т. Е. Высокой степени сцепления , (помните, что конструктор - это особый вид метода в Java.)

High Cohesion. Один класс должен иметь только одну роль. Например: класс автомобиля должен производить только автомобильные объекты, а не велосипеды, грузовики, самолеты и т. Д. Но класс Car может иметь некоторые особенности (поведение), которые принадлежат только ему.

Поэтому при разработке java язык программирования. Разработчики языка думали, что позволить разработчикам придерживаться какого-либо поведения класса для себя только путем создания статического метода.

Код ниже фрагмента пытается переопределить статический метод, но не будет встречаться с какой-либо ошибкой компиляции.

public class Vehicle {
static int VIN;

public static int getVehileNumber() {
    return VIN;
}}

class Car extends Vehicle {
static int carNumber;

public static int getVehileNumber() {
    return carNumber;
}}

Это потому, что здесь мы не переопределяем метод но мы просто повторно заявляем об этом. Java позволяет повторно объявить метод (статический / нестатический).

Удаление статического ключевого слова из метода getVehileNumber () класса Car приведет к ошибке компиляции. Поскольку мы пытаемся изменить функциональность статического метода, который принадлежит только классу Vehicle.

Кроме того, если getVehileNumber () объявлен как final, тогда код не будет компилироваться, поскольку последнее ключевое слово ограничивает программиста повторным объявлением метода.

public static final int getVehileNumber() {
return VIN;     }

В целом, это разработчики программного обеспечения для использования статических методов. Я лично предпочитаю использовать статические методы для выполнения некоторых действий без создания какого-либо экземпляра класса. Во-вторых, чтобы скрыть поведение класса из внешнего мира.

Ну ... ответ НЕТ, если вы думаете с точки зрения того, как должен работать метод overriden в Java. Но вы не получаете никакой ошибки компилятора, если пытаетесь переопределить статический метод. Это означает, что если вы попытаетесь переопределить, Java не остановит вас; но вы, конечно, не получаете того же эффекта, что и для нестатических методов. Переопределение на Java просто означает, что конкретный метод будет вызываться в зависимости от типа времени выполнения объекта, а не от его типа времени компиляции (что имеет место при переопределении статических методов). Хорошо ... любые догадки по причине, почему они ведут себя странно? Поскольку они являются методами класса и, следовательно, доступ к ним всегда разрешается во время компиляции только с использованием информации типа времени компиляции. Доступ к ним с использованием ссылок на объекты - это дополнительная свобода, предоставляемая разработчиками Java, и мы не должны думать о том, чтобы остановить эту практику только тогда, когда они ее ограничивают: -)

Пример : давайте попробуем посмотреть, что произойдет, если мы попробуем переопределить статический метод: -

class SuperClass {
// ......
public static void staticMethod() {
    System.out.println("SuperClass: inside staticMethod");
}
// ......
}

public class SubClass extends SuperClass {
// ......
// overriding the static method
public static void staticMethod() {
    System.out.println("SubClass: inside staticMethod");
}

// ......
public static void main(String[] args) {
    // ......
    SuperClass superClassWithSuperCons = new SuperClass();
    SuperClass superClassWithSubCons = new SubClass();
    SubClass subClassWithSubCons = new SubClass();

    superClassWithSuperCons.staticMethod();
    superClassWithSubCons.staticMethod();
    subClassWithSubCons.staticMethod();
    // ...
}
}

Выход : - SuperClass: inside staticMethod SuperClass: inside staticMethod SubClass: inside staticMethod

Обратите внимание на вторую строку вывода. Если бы staticMethod был переопределен, эта строка должна была бы быть идентичной третьей строке, поскольку мы вызываем «staticMethod ()» на объект Runtime Type как «SubClass», а не как «SuperClass». Это подтверждает, что статические методы всегда разрешаются с использованием только информации типа времени компиляции.

Какая польза от переопределения статических методов. Вы не можете вызвать статические методы через экземпляр.

MyClass.static1()
MySubClass.static1()   // If you overrode, you have to call it through MySubClass anyway.

EDIT: Похоже, что через неудачный надзор в дизайне языка вы можете вызвать статические методы через экземпляр. Как правило, никто этого не делает. Мой плохой.

Короткий ответ: это вполне возможно, но Java этого не делает.

Вот какой код, который иллюстрирует текущее состояние дел дел в 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.

Здесь случаи only , которые могут быть сюрпризом (и о котором идет речь), выглядят как первый случай :

«Тип времени выполнения не используется для определения того, какие статические методы вызывают, даже если вызывается с экземпляром объекта (obj.staticMethod())».

и последний случай last :

«При вызове статического метода из объектного метода класса выбранный статический метод является единственным, доступным из самого класса, и не из класса, определяющего тип времени выполнения объекта. "

Вызов с экземпляром объекта

Статический вызов разрешен во время компиляции, тогда как вызов нестатического метода разрешен во время выполнения. Обратите внимание, что хотя статические методы унаследованы (от родителя), они не переопределены (дочерним). Это может быть неожиданностью, если вы ожидали иначе.

Вызов из метода объекта

Вызов метода [) разрешается с использованием типа времени выполнения, но статические вызовы метода class разрешаются с использованием типа времени компиляции (объявленного).