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

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

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

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

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

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

Это не.

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: Абстрактные интерфейсы и методы абстрактного интерфейса

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

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

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

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

И

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

[...]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример:

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

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

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

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

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

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

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

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

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

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

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