Зачем использовать статический вложенный интерфейс в Java?

Ключевое слово static в приведенном выше примере является избыточным (вложенный интерфейс автоматически становится "статическим") и может быть удален без влияния на семантику; Я бы рекомендовал его удалить. То же самое касается "общедоступных" в методах интерфейса и "общедоступного финала" в полях интерфейса - модификаторы избыточны и просто добавляют беспорядок в исходный код.

В любом случае разработчик просто объявляет интерфейс с именем 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 неплохо с этим).

Интерфейсы-члены неявно статичны. Модификатор static в вашем примере можно удалить без изменения семантики кода. См. Также Спецификацию языка Java 8.5.1. Объявления типов статических элементов

Внутренний интерфейс должен быть статическим, чтобы к нему можно было получить доступ. Интерфейс связан не с экземплярами класса, а с самим классом, поэтому доступ к нему будет осуществляться с помощью Foo.Bar, например:

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

В большинстве случаев это не отличается от статического внутреннего класса.

Ответ Джесси близок, но я думаю, что есть лучший код, демонстрирующий, почему внутренний интерфейс может быть полезен. Прежде чем продолжить, посмотрите на приведенный ниже код. Сможете ли вы понять, чем полезен внутренний интерфейс? Ответ заключается в том, что класс DoSomethingAlready может быть создан с помощью любого класса, реализующего A и C; не только конкретный класс Zoo. Конечно, этого можно достичь, даже если AC не является внутренним, но представьте, что объединяете более длинные имена (не только 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. Возможно, автор намеревался использовать 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;
  }
}

Без статики вышеуказанное не удалось бы скомпилировать. Преимущество этого заключается в том, что вам не нужен новый исходный файл только для объявления интерфейса. Он также визуально связывает интерфейсную панель с классом Foo, поскольку вам нужно написать Foo.Bar, и подразумевает, что класс Foo что-то делает с экземплярами Foo.Bar.

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

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

Прекрасным примером полезности «статических» методов является класс Math. Все методы в Math статичны. Это означает, что вам не нужно изо всех сил создавать новый экземпляр, объявлять переменные и сохранять их в еще большем количестве переменных, вы можете просто ввести свои данные и получить результат.

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

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