Навіщо статичний вкладений інтерфейс використовуватиметься на Java?

Щойно я знайшов статичний вкладений інтерфейс у нашій кодовій базі.

class Foo {
    public static interface Bar {
        /* snip */
    }
    /* snip */
}

Я ніколи цього не бачив. Оригінальний розробник недоступний. Тому я повинен запитати ТА:

Які семантики стоять за статичним інтерфейсом? Що зміниться, якщо я видалю static? Навіщо хтось це робити?

Статичне ключове слово у наведеному вище прикладі є зайвим (вкладений інтерфейс автоматично "статичний") і його можна видалити, не впливаючи на семантику; Я рекомендував би його зняти. Те ж саме стосується "public" щодо методів інтерфейсу та "public final" для полів інтерфейсу - модифікатори є зайвими та просто додають захаращення у вихідний код.

Так чи інакше, розробник просто оголошує інтерфейс під назвою Foo.Bar. Більше немає зв'язку з класом, що вкладається, за винятком того, що код, який не може отримати доступ до Foo, також не зможе отримати доступ до Foo.Bar. (З вихідного коду - байт-код або відображення можуть отримати доступ до Foo.Bar, навіть якщо Foo є приватним пакетом!)

Створювати вкладений інтерфейс таким чином прийнятно, якщо ви очікуєте, що він буде використовуватися лише із зовнішнього класу, щоб не створити нове ім’я верхнього рівня. Наприклад:

public class Foo {
    public interface Bar {
        void callback();
    }
    public static void registerCallback(Bar bar) {...}
}
// ...elsewhere...
Foo.registerCallback(new Foo.Bar() {
    public void callback() {...}
});

На питання було дано відповідь, але одна з вагомих причин використовувати вкладений інтерфейс - це якщо його функція безпосередньо пов'язана з класом, в якому він знаходиться. Хорошим прикладом цього є Listener. Якщо у вас був клас, Fooі ви хотіли, щоб інші класи могли слухати події на ньому, ви могли оголосити інтерфейс з ім'ям FooListener, що нормально, але, напевно, було б більш зрозумілим оголосити вкладений інтерфейс і реалізувати ці інші класи Foo.Listener( вкладений клас Foo.Eventнепогано поряд із цим).

Інтерфейси учасників неявно статичні. Статичний модифікатор у вашому прикладі можна видалити без зміни семантики коду. Дивіться також специфікацію мови Java 8.5.1. Статичні декларації про член

Для того, щоб отримати доступ, внутрішній інтерфейс повинен бути статичним. Інтерфейс асоціюється не з екземплярами класу, а з самим класом, тому до нього можна отримати доступ Foo.Bar:

public class Baz implements Foo.Bar {
   ...
}

У більшості випадків це не відрізняється від статичного внутрішнього класу.

Відповідь Джессі близька, але я думаю, що є кращий код, який продемонструє, чому внутрішній інтерфейс може бути корисним. Подивіться на код нижче, перш ніж читати далі. Чи можете ви знайти, чому внутрішній інтерфейс корисний? Відповідь полягає в тому, що клас DoSomethingAlready може бути примірник будь-якого класу, який реалізує A і C; не тільки конкретний клас Зоопарк. Звичайно, цього можна досягти, навіть якщо зміна струму не є внутрішнім, але уявіть, як об'єднати довші імена (не лише A і C), і робити це для інших комбінацій (скажімо, A і B, C і B тощо), і ви легко подивіться, як все виходить з-під контролю. Не кажучи вже про те, що люди, які переглядають ваше початкове дерево, будуть переповнені інтерфейсами, які мають сенс лише в одному класі. Отже, підсумовуючи,внутрішній інтерфейс дозволяє будувати власні типи та покращує їх інкапсуляцію .

class ConcreteA implements A {
 :
}

class ConcreteB implements B {
 :
}

class ConcreteC implements C {
 :
}

class Zoo implements A, C {
 :
}

class DoSomethingAlready {
  interface AC extends A, C { }

  private final AC ac;

  DoSomethingAlready(AC ac) {
    this.ac = ac;
  }
}

Щоб відповісти на ваше запитання дуже безпосередньо, подивіться на Map.Entry.

Map.Entry

також це може бути корисно

Запис в статичний вкладений інтерфейс

Зазвичай я бачу статичні внутрішні класи. Статичні внутрішні класи не можуть посилатися на містять класи, де нестатичні класи можуть. Якщо ви не зіткнетеся з деякими зіткненнями пакетів (там вже є інтерфейс під назвою Bar у тому ж пакеті, що і Foo), я думаю, я б створив його власний файл. Також може бути дизайнерським рішенням застосувати логічний зв'язок між Foo та Bar. Можливо, автор задумав використовувати Бар лише з Foo (хоча статичний внутрішній інтерфейс цього не нав'яже, а лише логічне з'єднання)

Якщо ви зміните клас Foo на інтерфейс Foo, ключове слово "public" у наведеному вище прикладі також буде зайвим.

Інтерфейс, визначений в іншому інтерфейсі, буде неявно публічним статичним.

У 1998 році Філіп Вадлер запропонував різницю між статичними інтерфейсами та нестатичними інтерфейсами.

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

Наприклад, він запропонував вирішити проблему вираження , яка полягає в невідповідності між виразом як "наскільки може виражати ваша мова" з одного боку, та виразом як "термінами, які ви намагаєтесь представляти вашою мовою", а з іншого - .

Приклад різниці між статичними та нестатичними вкладеними інтерфейсами можна побачити в його зразковому коді :

// This code does NOT compile
class LangF<This extends LangF<This>> {
    interface Visitor<R> {
        public R forNum(int n);
    }

    interface Exp {
        // since Exp is non-static, it can refer to the type bound to This
        public <R> R visit(This.Visitor<R> v);
    }
}

Його пропозиція ніколи не робила цього в Java 1.5.0. Отже, всі інші відповіді правильні: немає різниці в статичних та нестатичних вкладених інтерфейсах.

У Java статичний інтерфейс / клас дозволяє використовувати інтерфейс / клас, як клас вищого рівня, тобто він може бути оголошений іншими класами. Отже, ви можете:

class Bob
{
  void FuncA ()
  {
    Foo.Bar foobar;
  }
}

Без статики вищезгадане не вдалося б скласти. Перевагою цього є те, що вам не потрібен новий вихідний файл лише для оголошення інтерфейсу. Він також візуально асоціює інтерфейс Bar із класом Foo, оскільки вам потрібно написати Foo.Bar, і це означає, що клас Foo робить щось із екземплярами Foo.Bar.

Опис типів класів на Java .

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

Ідеальним прикладом корисних "статичних" методів є клас Math. Всі методи в математиці є статичними. Це означає, що вам не доведеться виходити зі свого шляху, робити новий примірник, оголошувати змінні та зберігати їх у ще більше змінних, ви можете просто ввести свої дані та отримати результат.

Статична статистика не завжди така корисна. Наприклад, якщо ви робите порівняння випадків, можливо, ви захочете зберігати дані декількома різними способами. Ви не можете створити три статичні методи з однаковими підписами. Вам потрібні 3 різні екземпляри, нестатичні, і тоді ви можете і порівнювати, тому що якщо вони статичні, дані не змінюватимуться разом із введенням.

Статичні методи хороші для одноразових повернень та швидких розрахунків або легко отриманих даних.