2012-09-20 11 views
10

¿Por qué utilizamos public static final declaración de variables de instancia en una interfaz Java?
Todas las variables son implícitamente public static final en una interfaz Java.
Es una buena práctica de codificación usar public static final en variable constante aunque se declara dentro de una interfaz.
Declaración final estática pública de una variable de instancia en las interfaces JAVA

Por ejemplo:

public interface TestInterface{ 

public static final String EX_CONSTANT = "ABC"; 
public static final int EX_INT_CONSTANT = 5; 
public static final double EX_DOUBLE = 5.0; 
public static final Integer EX_INTEGER = 10; 

} 
+0

Puede hacer variables de tipo interfaz si la interfaz es implementada por la clase? He leído que esta es una mejor manera de crear una variable en una clase porque si agrega nuevos métodos no tiene que cambiar cada instancia de la variable en la clase. clase A implementar Binterface {Binterface = myInterface; luego llame a los métodos en la interfaz al igual que una definición de clase normal. ¿Por qué sería este el caso y qué beneficio podría obtener de tal declaración? –

Respuesta

11

El uso de una sintaxis uniforme en ambas clases e interfaces simplifica la refactorización.

Es posible que desee convertir su interface en un class algún lugar en el futuro, o mover estos campos en una clase, y obtendrá una diferencia semántica si usted pasa por alto algunos campos definidos y sin public static final (por supuesto, tenemos herramientas para refactorización, pero no obstante).

Creo que es lo mismo que el soporte de la anotación @Overriden para implementaciones de métodos declarados en interfaces que se introdujeron en Java 6 - es redundante en su forma actual, pero puede ser útil en caso de refactorización.

+1

muchos errores 'en el presente' y las preguntas SO también se evitarían si las personas usaran @Override :) – Affe

3

OMI, la interfaz es un contrato. Una vez que las variables son declaradas o definidas, no van a cambiar. Es por eso que generalmente los hacemos public static final.

La legibilidad es otro factor que hace que la declaración sea redundante.

+5

Pero las variables en la interfaz por defecto público, estático y final. Entonces, ¿por qué tenemos que usar esas palabras clave? –

5

No lo creo. Todas las variables de la interfaz son implícitamente públicas estáticas finales por lo que no es necesario marcarlas igual.

2

Es cierto que es redundante. Por lo general, las personas simplemente no saben que están implícitamente public static final y lo declaran de todos modos. Lo mismo ocurre con las cosas como declarar:

public abstract interface Test { // Interfaces are always abstract 
    public void testMethod(); // Interface methods are always public 
    abstract void anotherTestMethod(); // Also redundant 
} 

Por lo general, solo se reduce al hecho de que la gente no sabe que no es así tienen que declarar que de un modo u otro. Una vez hablé con alguien (que era un programador experimentado) que pensó que se requiere el caso default en switch o no se compilará.

Dicho esto, el único argumento para agregarlos es que aclaran cuál es su visibilidad real y qué es realmente. Se trata de una cuestión de legibilidad y aclaración, y si incluirlas es irrelevante en términos de cómo se comporta realmente.

+0

¿Por qué utilizamos la interfaz abstracta? Como la interfaz es implícitamente abstracta. –

+0

Ese es mi punto es que algunas personas lo incluyen simplemente para aclarar que es abstracto o porque no saben que no necesitan agregarlo. No hay una razón funcional para usarlo, solo razones subjetivas que varían de persona a persona – Brian

+1

Sí ... lo tengo ... Y gracias. –

2

Cuando se trabaja en un equipo de programadores, se encuentra programadores jóvenes que no conocen el hecho de que por defecto las variables son public static final de en la interfaz, y ver las variables declaradas de esa manera les dará información adicional sobre la interfaz y el uso de sus variables.

+0

Siempre podría decirles, o ellos siempre podrían aprender el idioma. – EJP

1

Tiene razón: es redundante. No me gusta agregar sintaxis redundante en cualquier momento. Sin embargo, la práctica sí tiene sus adeptos. A algunos también les gusta agregar paréntesis alrededor de las expresiones de retorno, basándose en el hecho falaz de que es como una declaración 'si'; paréntesis adicionales para 'aclarar' las expresiones aritméticas que un niño de tercer grado entendería; etc. Todo es parte del rico tapiz de la vida.

4

Del libro Effective Java por Joshua Bloch

artículo 19: Use sólo las interfaces para definir tipos

Cuando una clase implementa una interfaz, la interfaz sirve como un tipo que puede ser usado para referirse a instancias de la clase. Que una clase implemente una interfaz debería decir algo acerca de lo que un cliente puede hacer con las instancias de la clase . No es apropiado definir una interfaz para ningún otro propósito.

Un tipo de interfaz que no supera esta prueba es la llamada interfaz constante. Tal interfaz no contiene ningún método; consiste únicamente en campos finales estáticos, cada exportando una constante. Las clases que usan estas constantes implementan la interfaz a evitan la necesidad de calificar nombres constantes con un nombre de clase. Este es un ejemplo:

// Constant interface antipattern - do not use! 
public interface PhysicalConstants { 
    // Avogadro's number (1/mol) 
    static final double AVOGADROS_NUMBER = 6.02214199e23; 
    // Boltzmann constant (J/K) 
    static final double BOLTZMANN_CONSTANT = 1.3806503e-23; 
    // Mass of the electron (kg) 
    static final double ELECTRON_MASS = 9.10938188e-31; 
} 

El patrón de interfaz constante es un mal uso de interfaces. Que una clase use algunas constantes internamente es un detalle de implementación. Implementar una interfaz constante hace que este detalle de implementación se filtre en la API exportada de la clase. Es no tiene ninguna consecuencia para los usuarios de una clase que la clase implementa una interfaz constante . De hecho, incluso puede confundirlos. Peor aún, representa un compromiso: si en una versión futura la clase se modifica para que ya no necesite usar las constantes, aún debe implementar la interfaz para garantizar la compatibilidad binaria. Si una clase no final implementa una interfaz constante, todas sus subclases tendrán sus espacios de nombres contaminados por las constantes en la interfaz.

Hay varias interfaces constantes en las bibliotecas de la plataforma Java, como java.io.ObjectStreamConstants. Estas interfaces deben considerarse anomalías y no deben emularse.

Si desea exportar constantes, hay varias opciones razonables. Si las constantes están estrechamente vinculadas a una clase o interfaz existente, debe agregarlas a la clase o interfaz. Por ejemplo, todas las clases primitivas numéricas encuadradas, , como Integer y Double, exportan constantes MIN_VALUE y MAX_VALUE. Si las constantes se ven mejor como miembros de un tipo enumerado, debe exportarlos con un tipo de enumeración (Ítem 30). De lo contrario, debe exportar las constantes con una clase de utilidad no instalable (Artículo 4). Aquí está una versión de la clase utilidad del ejemplo anterior PhysicalConstants:

// Constant utility class 
package com.effectivejava.science; 

public class PhysicalConstants { 
    private PhysicalConstants() { 
    } // Prevents instantiation 

    public static final double AVOGADROS_NUMBER = 6.02214199e23; 
    public static final double BOLTZMANN_CONSTANT = 1.3806503e-23; 
    public static final double ELECTRON_MASS = 9.10938188e-31; 
} 

Normalmente una clase de utilidad requiere que los clientes para calificar nombres constantes con un nombre de clase , por ejemplo, PhysicalConstants.AVOGADROS_NUMBER. Si realiza un uso pesado de de las constantes exportadas por una clase de utilidad, puede evitar la necesidad de calificar las constantes con el nombre de clase haciendo uso de la instalación de importación estática, presentada en la versión 1.5:

// Use of static import to avoid qualifying constants 
import static com.effectivejava.science.PhysicalConstants.*; 
public class Test { 
    double atoms(double mols) { 
     return AVOGADROS_NUMBER * mols; 
    } 
... 
// Many more uses of PhysicalConstants justify static import 
} 

En resumen, las interfaces deben utilizarse sólo para definir tipos. No deberían usarse para exportar constantes.

+0

+1 Por una respuesta excelente, señor. –

Cuestiones relacionadas