clase interna dentro de la interfaz

¿Es posible crear una clase interna dentro de una interfaz? Si es así, ¿por qué creamos así? De todas formas, ¿no vamos a crear ningún objeto de interfaz?

¿Ayudan en cualquier proceso de Desarrollo?

Sí, puedes crear tanto una clase anidada como una clase interna dentro de una interfaz Java (ten en cuenta que, contrariamente a la creencia popular, no existe una ” clase interna estática “: esto simplemente no tiene sentido, no hay nada “interno” ni ” outter “class cuando una clase anidada es estática, por lo que no puede ser” estática interna “).

De todos modos, lo siguiente comstack bien:

public interface A { class B { } } 

Lo he visto solía poner algún tipo de “comprobador de contrato” directamente en la definición de la interfaz (bueno, en la clase anidada en la interfaz, que puede tener métodos estáticos, al contrario de la interfaz en sí, que no puede). Se ve así si recuerdo correctamente.

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

Tenga en cuenta que no estoy comentando sobre la utilidad de tal cosa, simplemente estoy respondiendo a su pregunta: se puede hacer y este es un tipo de uso que he visto hecho de él.

Ahora no voy a comentar sobre la utilidad de tal construcción y de lo que he visto: lo he visto, pero no es una construcción muy común.

La base de código 200KLOC aquí donde ocurre exactamente el tiempo cero (pero luego tenemos muchas otras cosas que consideramos malas prácticas que pasan exactamente el mismo tiempo que otras personas encontrarían perfectamente normales así que …).

Sí, podemos tener clases dentro de las interfaces. Un ejemplo de uso podría 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(); } 

Aquí el código tiene dos clases anidadas que son para encapsular información sobre objetos de eventos que luego se usan en definiciones de métodos como getKeyEvents (). Tenerlos dentro de la interfaz de entrada mejora la cohesión.

Un uso válido, en mi humilde opinión, es definir los objetos que son recibidos o devueltos por los métodos de interfaz adjuntos. Típicamente estructuras de retención de datos. De esa forma, si el objeto solo se usa para esa interfaz, tienes las cosas de una forma más cohesiva.

Por ejemplo:

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

Pero de todos modos … es solo una cuestión de gusto.

Cita de la especificación de Java 7 :

Las interfaces pueden contener declaraciones de tipo de miembro (§8.5).

Una statement de tipo de miembro en una interfaz es implícitamente estática y pública. Se permite especificar redundantemente uno o ambos de estos modificadores.

NO es posible declarar clases no estáticas dentro de una interfaz Java, lo que tiene sentido para mí.

Un caso de uso interesante es proporcionar una especie de implementación predeterminada para los métodos de interfaz a través de una clase interna como se describe aquí: https://stackoverflow.com/a/3442218/454667 (para superar el problema de la herencia de clase única).

Ciertamente es posible, y un caso en el que lo encontré útil es cuando una interfaz tiene que lanzar excepciones personalizadas. Usted puede mantener las excepciones con su interfaz asociada, lo cual creo que a menudo es mejor que ensuciar su árbol de fonts con montones de archivos de excepción triviales.

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

Sí, es posible tener definiciones de clases estáticas dentro de una interfaz, pero tal vez el aspecto más útil de esta característica es cuando se usan tipos enum (que son clases especiales de clases estáticas). Por ejemplo, puede tener algo como esto:

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

Lo que @Bachi menciona es similar a los rasgos en Scala y en realidad se implementa utilizando una clase anidada dentro de una interfaz. Esto se puede simular en Java. ¿Ver también los rasgos de java o el patrón de mixins?

Tal vez cuando desee construcciones más complejas como comportamientos de implementación diferentes, considere:

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

Esta es su interfaz y esta será la implementación:

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

Puede proporcionar algunas implementaciones estáticas, pero no será confuso, no lo sé.

Encontré un uso de este tipo de construcción.

  1. Puede usar esta construcción para definir y agrupar todas las constantes finales estáticas.
  2. Dado que es una interfaz, puede implementar esto en una clase.

Usted tiene acceso a todas las constantes agrupadas; el nombre de la clase actúa como espacio de nombres en este caso.

También puede crear clases estáticas “Helper” para la funcionalidad común de los objetos que implementan esta interfaz:

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

Necesito uno ahora mismo. Tengo una interfaz en la que sería conveniente devolver una clase única de varios de sus métodos. Esta clase solo tiene sentido como contenedor para las respuestas de los métodos de esta interfaz.

Por lo tanto, sería conveniente tener una definición de clase anidada estática, que está asociada solo a esta interfaz, ya que esta interfaz debería ser el único lugar donde alguna vez se cree esta clase contenedora de resultados.

Por ejemplo, rasgos (algo así como la interfaz con métodos implementados) en Groovy. Se comstackn en una interfaz que contiene una clase interna donde se implementan todos los métodos.