Java абстрактный интерфейс - PullRequest
192 голосов
/ 26 августа 2011

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

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

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


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

Ответы [ 9 ]

439 голосов
/ 26 августа 2011

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

Это не так.

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

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

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

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

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

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

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

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

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

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

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

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

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


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

36 голосов
/ 26 августа 2011

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

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

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

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

И

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

[...]

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

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

11 голосов
/ 26 августа 2011

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

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

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

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

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

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

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

7 голосов
/ 11 сентября 2014

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

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

3 голосов
/ 26 августа 2011

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

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

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

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

2 голосов
/ 26 августа 2011

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

2 голосов
/ 26 августа 2011

Это не обязательно. Это причуда языка.

0 голосов
/ 29 ноября 2014

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

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

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

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

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

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

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

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

Итак, Шаблон

Interface--->Abstract class/Abstract classes(depends)-->Concrete class
0 голосов
/ 25 июля 2013

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

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

Пример:

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, с которым я пробовал) компилирует класс, который реализует абстрактный интерфейс.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...