Java абстрактный интерфейс


197

Рассмотрим пример (который компилируется в Java)

public abstract interface Interface {
    public void interfacing();
    public abstract boolean interfacing(boolean really);
}

Почему интерфейс должен быть «объявлен» абстрактным? Есть ли другие правила, которые применяются с абстрактным интерфейсом?


Наконец: если abstractон устарел, почему он включен в Java? Есть ли история для абстрактного интерфейса?



5
Не дубликат, учитывая часть « Наконец: .... ».
aioobe

Этот связанный вопрос цитирует реальный пример: stackoverflow.com/questions/4380796/…
Raedwald

1
И почему Eclipse добавляет «абстрактный» по умолчанию, когда вы «извлекаете интерфейс»?
ModdyFire

@ModdyFire, пожалуйста, уточни?
Бухаке Синди

Ответы:


448

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

Это не.

public abstract interface Interface {
       \___.__/
           |
           '----> Neither this...

    public void interfacing();
    public abstract boolean interfacing(boolean really);
           \___.__/
               |
               '----> nor this, are necessary.
}

Интерфейсы и их методы неявно abstractи добавление этого модификатора не имеет значения.

Есть ли другие правила, которые применяются с абстрактным интерфейсом?

Нет, применяются те же правила. Метод должен быть реализован любым (конкретным) реализующим классом.

Если аннотация устарела, почему она включена в Java? Есть ли история для абстрактного интерфейса?

Интересный вопрос. Я откопал первый выпуск JLS, и даже там написано: «Этот модификатор устарел и не должен использоваться в новых программах Java» .

Ладно, копаем еще дальше ... После попадания в многочисленные неработающие ссылки мне удалось найти копию оригинальной спецификации Oak 0.2 (или "руководство"). Довольно интересное чтение, надо сказать, всего 38 страниц! :-)

В разделе 5 «Интерфейсы» приведен следующий пример:

public interface Storing {
    void freezeDry(Stream s) = 0;
    void reconstitute(Stream s) = 0;
}

И на полях написано

В будущем часть "= 0" объявления методов в интерфейсах может исчезнуть.

Предполагая, =0что его заменило abstractключевое слово, я подозреваю, что abstractв какой-то момент это было обязательно для методов интерфейса!


Связанная статья: Java: Абстрактные интерфейсы и методы абстрактного интерфейса


3
но абстракция сама по себе не устарела или? Он устарел для интерфейсов, но все еще существуют абстрактные классы и методы.
user85421

Спасибо ;-) Я думаю, что я, наконец, прибил источник для того, чтобы даже позволить abstractперед интерфейсными методами.
aioobe

13
Вот это да. Так что это устарело "по замыслу". Эти дизайнеры JLS всегда боялись что-то сломать, даже сломать вещи, которые так и не были выпущены ... :-)
Lukas Eder

@aioobe, вы должны быть поисковым роботом Google, о котором мы не знаем ... lol
Buhake Sindi

18
Btw. «public» также не требуется для методов в объявлении интерфейса ... они всегда public.
Rec

37

Это не обязательно, это необязательно, как publicв интерфейсных методах.

Смотрите JLS по этому вопросу:

http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html

9.1.1.1 абстрактные интерфейсы Каждый интерфейс неявно абстрактный. Этот модификатор устарел и не должен использоваться в новых программах.

И

9.4 Объявления абстрактных методов

[...]

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

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


7
JLS: разрешено, но категорически не рекомендуется излишне писать два предложения с одинаковым значением и почти точной формулировкой рядом друг с другом ...
n611x007

11

Не нужно объявлять интерфейс абстрактным.

Точно так же, как объявление всех этих методов общедоступными (какими они уже являются, если интерфейс открыт) или абстрактными (какими они уже являются в интерфейсе) является избыточным.

Никто не останавливает вас, хотя.

Другие вещи, которые вы можете явно указать, но не нужно:

  • вызовите super () в первой строке конструктора
  • extends Object
  • реализовать унаследованные интерфейсы

Есть ли другие правила, которые применяются с абстрактным интерфейсом?

Интерфейс уже "абстрактный". Повторное применение этого ключевого слова не имеет абсолютно никакого значения.


2
По-видимому, методы даже общедоступны, если сам интерфейс является закрытым для пакета.
Тило

7

Знайте, что весной это имеет не академический смысл. Абстрактный интерфейс является предупреждением для разработчика не использовать его для @Autowired. Я надеюсь, что spring / eclipse @Autowiredрассмотрит этот атрибут и предупредит / не удастся использовать его.

Реальный пример: прокси-серверу @Service в @Transnational для @Repository необходимо использовать одни и те же базовые методы, однако они должны использовать разные интерфейсы, которые расширяют этот абстрактный интерфейс @Autowired. (Я называю этот интерфейс XXXSpec)


+1 хороший удар, я выглядела безразлично для разделения непассивируемых инъекций сессионных бобов. Возможно я могу использовать findbugs / checkstyle для правила ....
Grim

3

Каждый интерфейс неявно абстрактный.
Этот модификатор устарел и не должен использоваться в новых программах.

[Спецификация языка Java - 9.1.1.1 abstractИнтерфейсы]

Также обратите внимание, что методы интерфейса являются неявными public abstract.
[Спецификация языка Java - 9.2 Члены интерфейса]

Почему эти модификаторы неявные? Нет другого модификатора (даже не модификатора « no modifier »), который был бы здесь полезен, поэтому вам не нужно явно его набирать.



2

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


-2

Абстрактный интерфейс не так избыточен, как все говорят, по крайней мере, в теории.

Интерфейс может быть расширен, как класс. Если вы разрабатываете Интерфейсную иерархию для своего приложения, у вас вполне может быть «Базовый» интерфейс, вы расширяете другие интерфейсы, но не хотите как объект сами по себе.

Пример:

public abstract interface MyBaseInterface {
    public String getName();
}

public interface MyBoat extends MyBaseInterface {
    public String getMastSize();
}

public interface MyDog extends MyBaseInterface {
    public long tinsOfFoodPerDay();
}

Вы не хотите, чтобы класс реализовывал MyBaseInterface, только два других, MMyDog и MyBoat, но оба интерфейса совместно используют интерфейс MyBaseInterface, поэтому имейте свойство name.

Я знаю, что это своего рода академический, но я подумал, что некоторые могут найти это интересным. :-)

В данном случае это просто «маркер», чтобы сигнализировать разработчикам интерфейса, который он не был разработан для самостоятельной реализации. Я должен отметить, что компилятор (по крайней мере, Sun / Ora 1.6, с которым я пробовал) компилирует класс, который реализует абстрактный интерфейс.


3
Я считаю, что вы совершенно не поняли мой вопрос.
Бухаке Синди

3
Я не согласен с этим рассуждением. Я думаю, что каждый интерфейс должен обеспечивать полностью функциональный набор функций, и поэтому каждый интерфейс может быть реализован сам по себе. Кроме того, у компилятора не было бы никаких причин отказываться компилировать класс, реализующий интерфейс, явно объявленный как абстрактный, поскольку все интерфейсы уже неявно являются абстрактными. Это полностью изменило бы значение «абстрактного» ключевого слова.
BladeCoder

-3

«Абстрактный интерфейс» - это лексическая конструкция: http://en.wikipedia.org/wiki/Lexical_analysis .

Это требуется компилятором, вы также можете написать interface.

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

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

Интерфейс - это чистый абстрактный тип данных, который представляет функции объекта, который он захватывает или представляет.

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

Если ваш конкретный класс не реализует все функции, он снова становится абстрактным, потому что у вас есть реализация вашей мысли, идеи или абстрактности, но она не завершена, вы указываете ее по abstractклассу.

Конкретным классом будет класс / набор классов, которые будут полностью отражать абстрактность, которую вы пытаетесь охватить классом XYZ.

Таким образом, шаблон

Interface--->Abstract class/Abstract classes(depends)-->Concrete class

1
Этот ответ не отвечает на мой вопрос вообще. Также "It seams like you are new to Java. В самом деле?
Бухаке Синди,

«аннотация устарела»
Маниш

(1) «abstract устарел» -> если они удаляют его и компилятор перестает его распознавать, тогда предыдущая версия исходного кода, использующая «abstract interface», не будет компилироваться в более новой версии. Они должны поддерживать обратную совместимость. Когда вы определяете абстрактный интерфейс, значение ключевого слова интерфейса застревает вместе с его «абстрактным», что является намного более чистой версией, однако для опытных программистов, таких как вы, они предоставили ярлык «интерфейс» .. ваш вопрос похож на i = i + 1 == > я ++ .. выбор за тобой, что ты выберешь: D
Manish

Посмотрите на принятый ответ. Я знаю abstract, устарел в интерфейсе. Я хотел знать, почему это все еще приемлемо и какова история abstractинтерфейса. Вы даете мне руководство по Java 101 по абстрактному интерфейсу.
Бухаке Синди,

Это не лексическая конструкция. Это синтаксис. Семантически это избыточно. Это не 'требуется компилятором'. Часть о пространстве / времени просто пустяковая. Ни одна из этих глупостей не отвечает на вопрос, который был задан. Не используйте форматирование кода для текста, который не является кодом.
Маркиз Лорн
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.