En Java, se enseña que las variables se deben mantener en privado para permitir una mejor encapsulación, pero ¿qué pasa con las constantes estáticas? Este:'public static final' o 'private static final' con getter?
public static final int FOO = 5;
sería equivalente en consecuencia a esto:
private static final int FOO = 5;
...
public static getFoo() { return FOO; }
Pero lo que es mejor la práctica?
Hay una razón para no usar una constante directamente en su código.
Supongamos que FOO puede cambiar más tarde (pero aún así permanecer constante), por ejemplo, public static final int FOO = 10;. No debería romper nada mientras nadie sea lo suficientemente estúpido como para codificar el valor directamente ¿no?
No. El compilador de Java insertará constantes como Foo arriba en el código de llamada, es decir someFunc(FooClass.FOO); se convierte en someFunc(5);. Ahora bien, si recompila su biblioteca pero no el código de llamada, puede terminar en situaciones sorprendentes. Eso se evitará si usas una función: el JIT aún lo optimizará, así que no hay ningún rendimiento real allí.
Interesante, nunca me di cuenta de esto. Sin embargo, nunca encontré constantes con getters en la naturaleza. –
Gracias por la información, parece que las constantes privadas y getters son opciones empíricamente más seguras y debería considerarse una mejor práctica. –
@Chris Depende de cuáles sean sus constantes: hay muchas constantes que están escritas en piedra (por ejemplo, "Pi" es poco probable que resulte ser 3 después de todos estos años;)) entonces no condenaría el uso de constantes públicas en todos los casos. Pero uno debe tener esto en cuenta, porque la depuración de ese problema es extremadamente horrible. – Voo
Dado que una variable final no se puede cambiar más adelante si va a utilizarla como una constante global, solo haga que sea pública sin necesidad de getter.
Solo si estás absolutamente seguro de que nunca cambiarás la variable final, el compilador introduce las constantes, lo que puede llevar a resultados extremadamente sorprendentes si cambian más adelante y no recompilas todo. Edit: Imaginé, eso es vale la pena una respuesta para que sea un poco más prominente. – Voo
Getter no tiene sentido aquí y lo más probable es que esté enmarcado por la JVM. Solo quédate con la constante pública.
La idea detrás de la encapsulación es proteger los cambios no deseados de una variable y ocultar la representación interna. Con constantes, no tiene mucho sentido.
El primero si el resultado getFoo es coherente y no necesita evaluación en tiempo de ejecución.
La ventaja de utilizar setter y getter en miembro es poder sobreescribir. Esto no es válido para "métodos" estáticos (más bien funciones)
Tampoco hay manera de definir interfaces de métodos estáticos.
Me gustaría ir con el acceso de campo
me quedaría con el getFoo(), ya que le permite cambiar la puesta en práctica en el futuro sin necesidad de cambiar el código de cliente. Como señaló @Tomasz, la JVM probablemente alineará su implementación actual, por lo que paga una gran parte de la penalización de rendimiento.
Utilice los variales fuera de la clase como:
public def FOO:Integer = 5;
Si encapsulación no es su prioridad. De lo contrario, use la segunda variante para que exponga un método y no la variable.
private static final int FOO = 5;
...
public static getFoo() { return FOO; }
También es una mejor práctica para el mantenimiento de código el no depender de las variables. Recuerde que "la optimización prematura es la raíz de todo mal".
La votación para cerrar no es constructiva (según los comentarios obstinados que ya se ofrecen). Es 'FOO' realmente una constante? ¿La clase proporciona 'FOO' como parte de una API? ¿O parte de una aplicación de punto final? Hay constantes matemáticas que nunca cambian. También hay indicadores de bits que nunca deberían cambiar (ver SWT). Entonces la respuesta es "Depende." –