¿Por qué se utilizaría una interfaz anidada estática en Java?

Acabo de encontrar una interfaz anidada estática en nuestra base de código.

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

Nunca he visto esto antes. El desarrollador original está fuera de alcance. Por lo tanto, tengo que preguntar SO:

¿Cuáles son las semánticas detrás de una interfaz estática? ¿Qué cambiaría si elimino el static? ¿Por qué alguien haría esto?

La palabra clave estática en el ejemplo anterior es redundante (una interfaz anidada es automáticamente "estática") y se puede eliminar sin ningún efecto en la semántica; Recomendaría que se elimine. Lo mismo ocurre con "público" en los métodos de interfaz y "público final" en los campos de interfaz: los modificadores son redundantes y simplemente agregan desorden al código fuente.

De cualquier manera, el desarrollador simplemente declara una interfaz llamada Foo.Bar. No hay más asociación con la clase que lo encierra, excepto que el código que no puede acceder a Foo tampoco podrá acceder a Foo.Bar. (Desde el código fuente: ¡el bytecode o la reflexión pueden acceder a Foo.Bar incluso si Foo es un paquete privado!)

Es un estilo aceptable crear una interfaz anidada de esta manera si espera que se use solo desde la clase externa, de modo que no cree un nuevo nombre de nivel superior. Por ejemplo:

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

La pregunta ha sido respondida, pero una buena razón para usar una interfaz anidada es si su función está directamente relacionada con la clase en la que se encuentra. Un buen ejemplo de esto es a Listener. Si tuviera una clase Fooy quisiera que otras clases pudieran escuchar eventos en ella, podría declarar una interfaz llamada FooListener, que está bien, pero probablemente sería más claro declarar una interfaz anidada e implementar esas otras clases Foo.Listener( una clase anidada Foo.Eventno es mala junto con esto).

Las interfaces de los miembros son implícitamente estáticas. El modificador estático en su ejemplo se puede eliminar sin cambiar la semántica del código. Consulte también la Especificación del lenguaje Java 8.5.1. Declaraciones de tipo de miembro estático

Una interfaz interna tiene que ser estática para poder acceder. La interfaz no está asociada con instancias de la clase, sino con la clase misma, por lo que se accedería de esta Foo.Barmanera:

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

En la mayoría de los casos, esto no es diferente de una clase interna estática.

La respuesta de Jesse es cercana, pero creo que hay un mejor código para demostrar por qué una interfaz interna puede ser útil. Mire el código a continuación antes de seguir leyendo. ¿Puedes encontrar por qué la interfaz interna es útil? La respuesta es que la clase DoSomethingAlready se puede instanciar con cualquier clase que implemente A y C; no solo la clase concreta Zoo. Por supuesto, esto se puede lograr incluso si AC no es interno, pero imagine concatenar nombres más largos (no solo A y C), y haciendo esto para otras combinaciones (digamos, A y B, C y B, etc.) y usted fácilmente ver cómo las cosas se salen de control. Sin mencionar que las personas que revisan su árbol de origen se verán abrumadas por las interfaces que son significativas solo en una clase.Una interfaz interna permite la construcción de tipos personalizados y mejora su encapsulación .

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 su pregunta muy directamente, mire Map.Entry.

Map.Entry

También esto puede ser útil

Entrada de blog de Inerfaces anidadas estáticas

Típicamente veo clases internas estáticas. Las clases internas estáticas no pueden hacer referencia a las clases que contienen, mientras que las clases no estáticas sí. A menos que se encuentre con algunas colisiones de paquetes (ya hay una interfaz llamada Bar en el mismo paquete que Foo), creo que lo convertiría en su propio archivo. También podría ser una decisión de diseño para imponer la conexión lógica entre Foo y Bar. Quizás el autor pretendía que Bar solo se usara con Foo (aunque una interfaz interna estática no impondrá esto, solo una conexión lógica)

Si cambia la clase Foo a la interfaz Foo, la palabra clave "pública" en el ejemplo anterior también será redundante porque

La interfaz definida dentro de otra interfaz será implícitamente pública estática.

En 1998, Philip Wadler sugirió una diferencia entre interfaces estáticas e interfaces no estáticas.

Hasta donde puedo ver, la única diferencia en hacer una interfaz no estática es que ahora puede incluir clases internas no estáticas; entonces el cambio no invalidaría ningún programa Java existente.

Por ejemplo, propuso una solución al problema de expresión , que es el desajuste entre la expresión como "cuánto puede expresar su idioma" por un lado y la expresión como "los términos que está tratando de representar en su idioma" por otro lado .

Un ejemplo de la diferencia entre interfaces anidadas estáticas y no estáticas se puede ver en su código de muestra :

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

Su sugerencia nunca lo hizo en Java 1.5.0. Por lo tanto, todas las demás respuestas son correctas: no hay diferencia en las interfaces anidadas estáticas y no estáticas.

En Java, la interfaz / clase estática permite que la interfaz / clase se use como una clase de nivel superior, es decir, puede ser declarada por otras clases. Entonces, puedes hacer:

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

Sin la estática, lo anterior no se podría compilar. La ventaja de esto es que no necesita un nuevo archivo fuente solo para declarar la interfaz. También asocia visualmente la barra de interfaz a la clase Foo, ya que debe escribir Foo.Bar e implica que la clase Foo hace algo con instancias de Foo.Bar.

Una descripción de los tipos de clase en Java .

Estático significa que cualquier parte de la clase del paquete (proyecto) puede acceder a él sin usar un puntero. Esto puede ser útil u obstaculizar dependiendo de la situación.

El ejemplo perfecto de las líneas útiles de los métodos "estáticos" es la clase Math. Todos los métodos en matemáticas son estáticos. Esto significa que no tiene que salir de su camino, hacer una nueva instancia, declarar variables y almacenarlas en aún más variables, solo puede ingresar sus datos y obtener un resultado.

La estática no siempre es tan útil. Si está haciendo una comparación de casos, por ejemplo, es posible que desee almacenar datos de varias maneras diferentes. No puede crear tres métodos estáticos con firmas idénticas. Necesita 3 instancias diferentes, no estáticas, y luego puede y comparar, porque si es estático, los datos no cambiarán junto con la entrada.

Los métodos estáticos son buenos para devoluciones únicas y cálculos rápidos o datos fáciles de obtener.