class interna dentro da interface

é possível criar uma class interna dentro de uma interface? Se sim, por que criamos assim? De qualquer forma, não vamos criar nenhum object de interface?

Eles ajudam em algum processo de desenvolvimento?

Sim, você pode criar uma class aninhada ou interna dentro de uma interface Java (observe que, ao contrário da crença popular, não existe uma ” class interna estática “: isso simplesmente não faz sentido, não há nada “interno” e não ” outter “class quando uma class aninhada é estática, portanto, não pode ser” interna estática “).

De qualquer forma, o seguinte compila bem:

public interface A { class B { } } 

Eu vi que costumava colocar algum tipo de “verificador de contrato” diretamente na definição da interface (bem, na class aninhada na interface, que pode ter methods estáticos, ao contrário da própria interface, que não pode). Parecendo assim, se bem me lembro.

 public interface A { static class B { public static boolean verifyState( A a ) { return (true if object implementing class A looks to be in a valid state) } } } 

Note que eu não estou comentando sobre a utilidade de tal coisa, eu estou simplesmente respondendo a sua pergunta: isso pode ser feito e este é um tipo de uso que eu vi feito dele.

Agora eu não vou comentar sobre a utilidade de tal constructo e desde que eu vi: eu já vi isso, mas não é uma construção muito comum.

200KLOC codebase aqui onde isso acontece exatamente o tempo zero (mas então nós temos muitas outras coisas que consideramos más práticas que acontecem exatamente com o tempo zero também, que outras pessoas acham perfeitamente normais, então …).

Sim, podemos ter classs dentro de interfaces. Um exemplo de uso poderia ser

 public interface Input { public static class KeyEvent { public static final int KEY_DOWN = 0; public static final int KEY_UP = 1; public int type; public int keyCode; public char keyChar; } public static class TouchEvent { public static final int TOUCH_DOWN = 0; public static final int TOUCH_UP = 1; public static final int TOUCH_DRAGGED = 2; public int type; public int x, y; public int pointer; } public boolean isKeyPressed(int keyCode); public boolean isTouchDown(int pointer); public int getTouchX(int pointer); public int getTouchY(int pointer); public float getAccelX(); public float getAccelY(); public float getAccelZ(); public List getKeyEvents(); public List getTouchEvents(); } 

Aqui o código tem duas classs aninhadas que são para encapsular informações sobre objects de events que são posteriormente usadas em definições de methods como getKeyEvents (). Tê-los dentro da interface de input melhora a coesão.

Um uso válido, IMHO, é definir objects que são recebidos ou retornados pelos methods da interface envolvente. Tipicamente estruturas de retenção de dados. Dessa forma, se o object for usado apenas para essa interface, você terá as coisas de maneira mais coesa.

Por exemplo:

 interface UserChecker { Ticket validateUser(Credentials credentials); class Credentials { // user and password } class Ticket { // some obscure implementation } } 

Mas de qualquer forma … é apenas uma questão de gosto.

Cite a partir da especificação do Java 7 :

As interfaces podem conter declarações de tipo de membro (§8.5).

Uma declaração de tipo de membro em uma interface é implicitamente estática e pública. É permitido especificar de forma redundante um ou ambos os modificadores.

Não é possível declarar classs não estáticas dentro de uma interface Java, o que faz sentido para mim.

Um caso de uso interessante é fornecer uma espécie de implementação padrão para methods de interface por meio de uma class interna, conforme descrito aqui: https://stackoverflow.com/a/3442218/454667 (para superar o problema da inheritance de class única).

Certamente é possível, e um caso em que achei útil é quando uma interface tem que lançar exceções personalizadas. Você mantém as exceções com sua interface associada, o que eu acho que geralmente é mais limpo do que jogar lixo em sua tree de fonts com montes de arquivos de exceção triviais.

 interface MyInterface { public static class MyInterfaceException extends Exception { } void doSomething() throws MyInterfaceException; } 

Sim, é possível ter definições de class estáticas dentro de uma interface, mas talvez o aspecto mais útil desse recurso seja ao usar tipos de enum (que são tipos especiais de classs estáticas). Por exemplo, você pode ter algo assim:

 public interface User { public enum Role { ADMIN("administrator"), EDITOR("editor"), VANILLA("regular user"); private String description; private Role(String description) { this.description = description; } public String getDescription() { return description; } } public String getName(); public void setName(String name); public Role getRole(); public void setRole(Role role); ... } 

O que o @Bachi menciona é semelhante a traços no Scala e é realmente implementado usando uma class aninhada dentro de uma interface. Isso pode ser simulado em Java. Veja também traços de java ou padrão de mixins?

Talvez quando você quiser construções mais complexas, como alguns comportamentos de implementação diferentes, considere:

  public interface A { public void foo(); public static class B implements A{ @Override public void foo(){ System.out.println("B foo"); } } } 

Essa é a sua interface e esse será o implementei:

  public class C implements A { @Override public void foo(){ AB b = new AB(); b.foo(); } public static void main(String[] strings) { C c = new C(); c.foo(); } } 

Pode fornecer algumas implementações estáticas, mas isso não será confuso, não sei.

Eu encontrei um uso para este tipo de construção.

  1. Você pode usar essa construção para definir e agrupar todas as constantes finais estáticas.
  2. Desde então, é uma interface que você pode implementar isso em uma class.

Você tem access a todas as constantes agrupadas; O nome da class atua como um namespace nesse caso.

Você também pode criar classs estáticas “Auxiliares” para funcionalidade comum para os objects que implementam essa interface:

 public interface A { static class Helper { public static void commonlyUsedMethod( A a ) { ... } } } 

Eu estou precisando de um agora. Eu tenho uma interface onde seria conveniente retornar uma class única de vários dos seus methods. Essa class só faz sentido como um contêiner para respostas de methods dessa interface.

Portanto, seria conveniente ter uma definição de class aninhada estática, que está associada somente a essa interface, já que essa interface deve ser o único lugar onde essa class de contêiner de resultados é criada.

Por exemplo, características (smth como interface com methods implementados) no Groovy. Eles são compilados para uma interface que contém uma class interna onde todos os methods são implementados.