¿Por qué todos los campos de una interfaz son implícitamente estáticos y finales?

Solo estoy tratando de entender por qué todos los campos definidos en una interfaz son implícitamente staticy final. La idea de mantener campos statictiene sentido para mí, ya que no puede tener objetos de una interfaz, pero ¿por qué lo son final(implícitamente)?

¿Alguien sabe por qué los diseñadores de Java optaron por crear los campos en una interfaz staticy final?

Una interfaz no puede tener comportamiento o estado porque está destinada a especificar solo un contrato de interacción, sin detalles de implementación. 'Sin comportamiento' se aplica al no permitir cuerpos de método / constructor o bloques de inicialización estáticos / de instancia. 'Ningún estado' se aplica permitiendo solo campos finales estáticos. Por lo tanto, la clase puede tener un estado (estado estático), pero la interfaz no infiere el estado de la instancia.

Por cierto: una constante en Java se define mediante un campo final estático (y por convención el nombre usa UPPER_CASE_AND_UNDERSCORES).

Razón de ser final

Cualquier implementación puede cambiar el valor de los campos si no están definidos como finales. Entonces se convertirían en parte de la implementación. Una interfaz es una especificación pura sin ninguna implementación.

Razón de ser static

Si son estáticos, pertenecen a la interfaz, y no al objeto, ni al tipo de tiempo de ejecución del objeto.

Hay un par de puntos que se pasan por alto aquí:

El hecho de que los campos en una interfaz sean implícitamente estáticos finales no significa que deban ser constantes en tiempo de compilación, o incluso inmutables. Puede definir, por ejemplo,

interface I {
  String TOKEN = SomeOtherClass.heavyComputation();
  JButton BAD_IDEA = new JButton("hello");
}

(Tenga en cuenta que hacer esto dentro de una definición de anotación puede confundir a javac , en relación con el hecho de que lo anterior en realidad se compila en un inicializador estático).

Además, la razón de esta restricción es más estilística que técnica, y a mucha gente le gustaría verla relajada .

Los campos deben ser estáticos porque no pueden ser abstractos (como pueden hacerlo los métodos). Debido a que no pueden ser abstractos, los implementadores no podrán proporcionar lógicamente la implementación diferente de los campos.

Los campos deben ser definitivos, creo, porque muchos implementadores diferentes pueden acceder a los campos, lo que permite que se puedan cambiar y puede ser problemático (como la sincronización). También para evitar que se vuelva a implementar (ocultar).

Solo mi pensamiento.

Considero que el requisito de que los campos sean finales es excesivamente restrictivo y un error de los diseñadores del lenguaje Java. Hay ocasiones, por ejemplo, en el manejo de árboles, en las que es necesario establecer constantes en la implementación que son necesarias para realizar operaciones en un objeto del tipo de interfaz. Seleccionar una ruta de código en la clase de implementación es un fastidio. La solución alternativa que utilizo es definir una función de interfaz e implementarla devolviendo un literal:

public interface iMine {
    String __ImplementationConstant();
    ...
}

public class AClass implements iMine {
    public String __ImplementationConstant(){
        return "AClass value for the Implementation Constant";
    }
    ...
}

public class BClass implements iMine {
    public String __ImplementationConstant(){
        return "BClass value for the Implementation Constant";
    }
    ...
}

Sin embargo, sería más simple, más claro y menos propenso a una implementación aberrante usar esta sintaxis:

public interface iMine {
    String __ImplementationConstant;
    ...
}

public class AClass implements iMine {
    public static String __ImplementationConstant =
        "AClass value for the Implementation Constant";
    ...
}

public class BClass implements iMine {
    public static String __ImplementationConstant =
        "BClass value for the Implementation Constant";
    ...
}

Especificación, contratos ... La instrucción de la máquina para el acceso al campo utiliza la dirección del objeto más el desplazamiento del campo. Dado que las clases pueden implementar muchas interfaces, no hay forma de hacer que el campo de interfaz no final tenga el mismo desplazamiento en todas las clases que extienden esta interfaz. Por lo tanto, se debe implementar un mecanismo diferente para el acceso al campo: dos accesos a la memoria (obtener el desplazamiento del campo, obtener el valor del campo) en lugar de uno más el mantenimiento de una especie de tabla de campo virtual (análogo de la tabla de método virtual). Supongo que simplemente no querían complicar jvm para una funcionalidad que se puede simular fácilmente a través de cosas (métodos) existentes.

En scala podemos tener campos en interfaces, aunque internamente se implementan como expliqué anteriormente (como métodos).

static:

Cualquier cosa (variable o método) que esté staticen Java se puede invocar como Classname.variablenameoClassname.methodname bien directamente. No es obligatorio invocarlo solo utilizando el nombre del objeto.

En la interfaz, los objetos no se pueden declarar y statichace posible invocar variables solo a través del nombre de la clase sin la necesidad del nombre del objeto.

final:

Ayuda a mantener un valor constante para una variable, ya que no se puede anular en sus subclases.