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

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

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

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

Чтобы ответить на ваш вопрос прямо, посмотрите на Map.Entry.

Map.Entry

также это может быть полезно

Запись в блоге о статических вложенных интерфейсах

Обычно я вижу статические внутренние классы. Статические внутренние классы не могут ссылаться на содержащиеся классы, тогда как нестатические классы могут. Если вы не столкнетесь с некоторыми конфликтами пакетов (уже есть интерфейс с именем Bar в том же пакете, что и Foo), я думаю, что я бы сделал его собственным файлом. Это также может быть дизайнерское решение для обеспечения логической связи между Foo и Bar. Возможно, автор намеревался использовать Bar только с Foo (хотя статический внутренний интерфейс не обеспечивает этого, просто логическое соединение)

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

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

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

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

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

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

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

Описание типов классов в 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() {...}
});

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

На вопрос был дан ответ, но одна из веских причин для использования вложенного интерфейса заключается в том, что его функция напрямую связана с классом, в котором он находится. Хорошим примером этого является Listener. Если у вас есть класс Foo, и вы хотите, чтобы другие классы могли прослушивать события на нем, вы могли бы объявить интерфейс с именем FooListener, что нормально, но, вероятно, было бы более ясно объявить вложенный интерфейс и иметь эти другие классы реализовать Foo.Listener (вместе с этим неплох и вложенный класс Foo.Event).

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

Если вы измените класс Foo на интерфейс Foo, ключевое слово public в приведенном выше примере также будет избыточным, потому что

interface defined inside another interface will implicitly public static.

В 1998 году Филип Вадлер предложил различие между статическими и нестатическими интерфейсами.

So far as I can see, the only difference in making an interface non-static is that it can now include non-static inner classes; so the change would not render invalid any existing Java programs.

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

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

// 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. Следовательно, все остальные ответы верны: нет разницы между статическими и нестатическими вложенными интерфейсами.