Почему нужно объявлять метод интерфейса Java как абстрактный?


143

Сегодня я использовал функцию рефакторинга «pull interface» в Eclipse, чтобы создать интерфейс на основе существующего класса. В диалоговом окне предлагается создать все новые методы нового интерфейса как «абстрактные» методы.

Какая польза от этого?

Я думал, что тот факт, что вам было разрешено объявлять методы интерфейса как абстрактные, был излишней и безвредной особенностью языка, что не особенно поощряется.

Почему Eclipse поддерживает такой стиль или почему кто-то добровольно решит это сделать?

Пояснение: я не спрашиваю, почему интерфейсные методы являются абстрактными, это очевидно. Я спрашиваю, почему кто-то явно решил пометить их как абстрактные, так как если они находятся в интерфейсе, они в любом случае являются абстрактными.

Ответы:


146

Согласно Спецификации языка Java , abstractключевое слово для интерфейсов устарело и больше не должно использоваться. (Раздел 9.1.1.1)

Тем не менее, с учетом склонности Java к обратной совместимости, я действительно сомневаюсь, что когда-либо будет иметь значение, присутствует ли abstractключевое слово.


1
Это было мое понимание (хотя я не был знаком с конкретным разделом JLS). Мне интересно, почему «Затмение» предложило мне вариант создания устаревшей маркировки ...
Ури

Подловил. Кто-то где-то должен был решить, что это была желательная «фича», и вставить ее. Вы знаете, один из тех
хитрых

18
Хотя это самый популярный ответ, он относится к неправильному разделу Спецификации; 9.1.1.1 описывает abstractключевое слово в объявлении самого интерфейса, а не его членов. @ Ниже приведен правильный ответ, который также содержит действительные источники ссылок.
Лохматая лягушка

39

«Преимущество этого» (добавление тезисов при объявлении методов интерфейса) в eclipse было бы старой проблемой совместимости с компилятором jdt eclipse в jdk1.3

Начиная с версии 1.4, библиотеки jdk больше не содержат абстрактные методы по умолчанию (в абстрактных классах, реализующих интерфейсы).
Это обманывает диагностику компилятора Eclipse 1.3, поскольку их реализация зависит от их существования.
Обратите внимание, что Javac 1.3 полностью отказывается работать с библиотеками 1.4 (используя опцию -bootclasspath).

Поскольку компилятор Eclipse, вероятно, находится на уровне соответствия 1.4 (см. Workbench>Preferences>Java>Compiler>JDK Compliance) Или использует как минимум 1,3 библиотеки классов, если используется режим соответствия 1.3, присутствие «абстрактного» не требуется в большинстве текущих проектов Eclipse.


3
Хорошая находка. Так что это функциональность, чтобы обойти более не существующую проблему в компиляторе Eclipse.
jdmichal

1
@jdmichal: точно, и это также более точный ответ на вопрос Ури.
VonC

39

Из Java SE 7 JLS (спецификация языка Java): «Разрешается, но не рекомендуется как вопрос стиля, избыточно указывать открытый и / или абстрактный модификатор для метода, объявленного в интерфейсе».

Для Java SE 5.0 : «Для совместимости со старыми версиями платформы Java разрешается, но не рекомендуется, из соображений стиля, избыточно указывать абстрактный модификатор для методов, объявленных в интерфейсах».


9

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


Это должен быть правильный ответ. Вот обновленная ссылка - см. Раздел «заметка»
mork

JLS не говорит, что ключевое слово устарело для методов в интерфейсах. В нем говорится: «Разрешается, но не рекомендуется в качестве стиля, избыточно указывать открытый и / или абстрактный модификатор для метода, объявленного в интерфейсе». JLS # 9.4 .
Маркиз Лорн

@EJP Я не говорил, что JLS заявил, что ключевое слово будет устаревшим, это было мое личное мнение;) Кстати, они отмечают, что это ключевое слово является «избыточным», что не совсем то же самое, что устаревшее, в этом вы, конечно, правы , Теперь, когда я знаю, я отредактирую ответ, чтобы уточнить это.
Даниэль Хиллер
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.