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

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

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

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

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

Ответ 1

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

Это не так.

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

Ответ 2

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

См. JLS:

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

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

9.4 Абстрактные декларации методов

[...]

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

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

Ответ 3

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

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

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

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

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

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

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

Ответ 4

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

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

Ответ 5

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

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

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

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

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

Пример:

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".

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

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

Ответ 9

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

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

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

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

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

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

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

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

Итак, шаблон

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