Por que uma interface aninhada estática seria usada em Java?

Acabei de encontrar uma interface aninhada estática em nossa base de código.

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

Eu nunca vi isso antes. O desenvolvedor original está fora de alcance. Portanto, eu tenho que perguntar SO:

Quais são as semânticas por trás de uma interface estática? O que mudaria se eu removesse o static? Por que alguém faria isso?

A palavra-chave estática no exemplo acima é redundante (uma interface aninhada é automaticamente "estática") e pode ser removida sem afetar a semântica; Eu recomendaria que fosse removido. O mesmo vale para "público" nos métodos de interface e "público final" nos campos de interface - os modificadores são redundantes e apenas adicionam confusão ao código-fonte.

De qualquer forma, o desenvolvedor está simplesmente declarando uma interface chamada Foo.Bar. Não há associação adicional com a classe envolvente, exceto que o código que não pode acessar o Foo também não poderá acessar o Foo.Bar. (Do código-fonte - o bytecode ou o reflexo podem acessar o Foo.Bar, mesmo que o Foo seja privado de pacotes!)

É um estilo aceitável criar uma interface aninhada dessa maneira, se você espera que ela seja usada apenas a partir da classe externa, para que você não crie um novo nome de nível superior. Por exemplo:

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

A pergunta foi respondida, mas um bom motivo para usar uma interface aninhada é se sua função estiver diretamente relacionada à classe em que está. Um bom exemplo disso é a Listener. Se você tivesse uma classe Fooe desejasse que outras classes pudessem ouvir eventos nela, poderia declarar uma interface com o nome FooListenerok, mas provavelmente seria mais claro declarar uma interface aninhada e implementar essas outras classes Foo.Listener( uma classe aninhada Foo.Eventnão é ruim junto com isso).

As interfaces dos membros são implicitamente estáticas. O modificador estático no seu exemplo pode ser removido sem alterar a semântica do código. Consulte também a Java Language Specification 8.5.1. Declarações de tipo de membro estático

Uma interface interna deve ser estática para ser acessada. A interface não está associada a instâncias da classe, mas à própria classe, portanto, seria acessada com Foo.Bar:

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

De muitas maneiras, isso não é diferente de uma classe interna estática.

A resposta de Jesse é próxima, mas acho que existe um código melhor para demonstrar por que uma interface interna pode ser útil. Veja o código abaixo antes de ler. Você consegue descobrir por que a interface interna é útil? A resposta é que a classe DoSomethingAlready pode ser instanciada com qualquer classe que implemente A e C; não apenas a classe concreta Zoo. Obviamente, isso pode ser alcançado mesmo que a CA não seja interna, mas imagine concatenar nomes mais longos (não apenas A e C), e faça isso para outras combinações (por exemplo, A e B, C e B, etc.) e você facilmente veja como as coisas saem de controle. Sem mencionar que as pessoas que revisam sua árvore de origem serão sobrecarregadas por interfaces que são significativas apenas em uma classe.uma interface interna permite a construção de tipos personalizados e melhora seu encapsulamento .

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;
  }
}

Para responder sua pergunta diretamente, consulte Map.Entry.

Map.Entry

também isso pode ser útil

Entrada do blog Static Nested Inerfaces

Normalmente, vejo classes internas estáticas. Classes internas estáticas não podem fazer referência às classes que contêm, enquanto classes não estáticas podem. A menos que você esteja enfrentando algumas colisões de pacotes (já existe uma interface chamada Bar no mesmo pacote que o Foo), acho que seria o próprio arquivo. Também poderia ser uma decisão de design para impor a conexão lógica entre Foo e Bar. Talvez o autor pretenda que o Bar seja usado apenas com Foo (embora uma interface interna estática não imponha isso, apenas uma conexão lógica)

Se você mudar a classe Foo para a interface Foo, a palavra-chave "public" no exemplo acima também será redundante porque

A interface definida dentro de outra interface implicitamente public estática.

Em 1998, Philip Wadler sugeriu uma diferença entre interfaces estáticas e não estáticas.

Até onde posso ver, a única diferença em tornar uma interface não estática é que agora ela pode incluir classes internas não estáticas; portanto, a alteração não invalidaria nenhum programa Java existente.

Por exemplo, ele propôs uma solução para o Problema da Expressão , que é a incompatibilidade entre expressão como "quanto sua linguagem pode expressar", por um lado, e expressão como "os termos que você está tentando representar em sua linguagem", por outro lado. .

Um exemplo da diferença entre interfaces aninhadas estáticas e não estáticas pode ser visto em seu código de amostra :

// 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);
    }
}

Sua sugestão nunca chegou ao Java 1.5.0. Portanto, todas as outras respostas estão corretas: não há diferença para interfaces aninhadas estáticas e não estáticas.

Em Java, a interface / classe estática permite que a interface / classe seja usada como uma classe de nível superior, ou seja, pode ser declarada por outras classes. Então, você pode fazer:

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

Sem o estático, o acima falharia ao compilar. A vantagem disso é que você não precisa de um novo arquivo de origem apenas para declarar a interface. Também associa visualmente a interface Bar à classe Foo, já que você precisa escrever Foo.Bar e implica que a classe Foo faz algo com instâncias de Foo.Bar.

Uma descrição dos tipos de classe em Java .

Estático significa que qualquer parte da classe do pacote (projeto) pode acessá-lo sem usar um ponteiro. Isso pode ser útil ou dificultar dependendo da situação.

O exemplo perfeito das utilidades dos métodos "estáticos" é a classe Math. Todos os métodos em matemática são estáticos. Isso significa que você não precisa sair do seu caminho, criar uma nova instância, declarar variáveis ​​e armazená-las em ainda mais variáveis; basta digitar seus dados e obter um resultado.

A estática nem sempre é útil. Se você estiver comparando casos, por exemplo, convém armazenar dados de várias maneiras diferentes. Você não pode criar três métodos estáticos com assinaturas idênticas. Você precisa de 3 instâncias diferentes, não estáticas e, em seguida, é possível comparar e, se for estático, os dados não serão alterados junto com a entrada.

Os métodos estáticos são bons para retornos únicos e cálculos rápidos ou dados facilmente obtidos.