Поскольку "краткий обзор" означает: "Реализации никакая функциональность", и "статичный" означают: "Существует функциональность, даже если у Вас нет экземпляра объекта". И это - логическое противоречие.
abstract
аннотация к методу указывает, что метод ДОЛЖЕН быть переопределен в подклассе.
В Java, static
участник (метод или поле) не может быть переопределен подклассами (это не обязательно верно на других объектно-ориентированных языках, посмотрите SmallTalk.) static
участник может быть скрытый , но это существенно отличается, чем [1 117] переопределенный .
, Так как статические участники не могут быть переопределены в подклассе, abstract
, аннотация не может быть применена к ним.
Как в стороне - другие языки действительно поддерживают статическое наследование, точно так же, как наследование экземпляра. С точки зрения синтаксиса те языки обычно требуют, чтобы имя класса было включено в оператор. Например, в Java, принимая Вы пишете код в ClassA, это эквивалентные операторы (если methodA () является статическим методом, и нет никакого метода экземпляра с той же подписью):
ClassA.methodA();
и
methodA();
В SmallTalk, имя класса не является дополнительным, таким образом, синтаксис (обратите внимание, что SmallTalk не использует. разделить "предмет" и "глагол", но вместо этого использует его в качестве разделителя оператора):
ClassA methodA.
, поскольку имя класса всегда требуется, корректная "версия" метода может всегда определяться путем пересечения иерархии классов. Если это имеет значение я действительно иногда отсутствую static
наследование, и был укушен отсутствием статического наследования в Java, когда я сначала запустил с него. Кроме того, SmallTalk вводится уткой (и таким образом не делает программы поддержки согласно контракту.) Таким образом это не имеет никакого abstract
модификатор для участников класса.
Вы не можете переопределить статический метод, таким образом делание его абстрактный было бы бессмысленно. Кроме того, статический метод в абстрактном классе принадлежал бы тому классу, а не переопределяющему классу, так не мог использоваться так или иначе.
Статический метод можно назвать без экземпляра класса. В Вашем примере можно назвать нечто bar2 (), но не foo.bar (), потому что для панели Вам нужен экземпляр. Следующий код работал бы:
foo var = new ImplementsFoo();
var.bar();
при вызове статического метода он будет всегда выполняться тот же код. В вышеупомянутом примере даже при переопределении bar2 в ImplementsFoo вызов к var bar2 () выполнил бы нечто bar2 ().
, Если bar2 теперь не имеет никакой реализации (это - то, что краткий обзор означает), можно назвать метод без реализации. Это очень вредно.
Плохой языковой дизайн. Было бы гораздо эффективнее вызывать статический абстрактный метод напрямую, чем создавать экземпляр только для использования этого абстрактного метода. Это особенно актуально при использовании абстрактного класса в качестве обходного пути для невозможности расширения enum, что является еще одним неудачным примером дизайна. Надеюсь, они устранят эти ограничения в следующем выпуске.