Абстрактний інтерфейс 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. Я сподіваюся, що весна / затемнення@Autowired розгляне цей атрибут і попередить / не зможе про звичаї таких.

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

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

[Специфікація мови Java - abstractінтерфейси 9.1.1.1 ]

Також зауважте, що методи учасників інтерфейсу неявно public abstract.
[Специфікація мови Java - 9.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, який я пробував), складає клас, який реалізує абстрактний інтерфейс.

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

Це вимагає компілятор, ви також могли написати interface.

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

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

Інтерфейс - це чистий абстрактний тип даних, який представляє особливості об'єкта, який він фіксує або представляє.

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

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

Конкретним класом буде клас / набір класів, який повністю зафіксує абстрактність, яку ви намагаєтеся захопити класом XYZ.

Отже, Шаблон є

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