Чому можна оголосити метод інтерфейсу Java абстрактним?

143

Я сьогодні використовував функцію рефакторингу Eclipse "тягнутий інтерфейс", щоб створити інтерфейс на основі існуючого класу. Діалогове вікно запропонувало створити всі нові методи нового інтерфейсу як "абстрактні" методи.

Яка б користь від цього?

Я вважав, що той факт, що вам було дозволено оголошувати методи інтерфейсу абстрактними, є зайвою і нешкідливою особливістю мови, яка не особливо заохочується.

Чому Eclipse підтримує такий стиль, або чому хтось добровільно вирішив би зробити це?

Уточнення: я не запитую, чому методи інтерфейсу абстрактні, це очевидно. Я запитую, чому явно вирішив би позначати їх як абстрактні, оскільки якщо вони знаходяться в інтерфейсі, вони все одно абстрактні.

— Урі
джерело

146

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

Але, маючи на увазі схильність Java до зворотної сумісності, я дійсно сумніваюся, що коли-небудь зміниться, чи є abstractключове слово.

— jdmichal
джерело

1

Це було моє розуміння (хоча я не був знайомий з конкретним розділом JLS). Мені цікаво, чому Eclipse запропонував би мені можливість створити застаріле маркування ...

— Урі

Поняв мене. Хтось десь повинен вирішити, що це бажана "особливість", і вкласти її. Знаєте, один із тих

— хитрих

18

Хоча це найкраща відповідь, вона посилається на неправильний розділ Специфікації; 9.1.1.1 описує abstractключове слово на оголошенні самого інтерфейсу, а не на його членах. @ Відповідь Вілла нижче правильна, а також містить дійсні джерела посилання.

— Shaggy Frog

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, наявність більшості "абстрактних" не потрібна у більшості поточних проектів затемнення.

— VonC
джерело

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 заявив, що ключове слово буде застарілим, це була моя особиста думка;) До речі, вони відзначають, що це ключове слово "зайве", що не зовсім те саме, що застаріле, в цьому ви маєте рацію, звичайно . Тепер, коли я знаю, я відредагую відповідь, щоб уточнити це.

— Даніель Гіллер