¿Por qué declarar una cadena (como final) y luego usarla?

8

En una típica clase de validador mvc de muelles, al insertar un valor de errorCode en el objeto Errores, ¿qué diferencia hay entre usar un String ( props.somefield.req) así?

errors.rejectValue("elementId", "props.somefield.req");

Versos una cadena final estática declarada?

private static final String SOMFIELD_REQ = "props.somefield.req"; ...
errors.rejectValue("elementId", SOMFIELD_REQ);

¿Mejora el rendimiento incluso de la más mínima manera? He leído algunas preguntas sobre el desbordamiento de la pila ( Cadena y final , ¿Tiene sentido definir una Cadena final en Java? ) Pero nadie respondió a esta pregunta de actualización de preguntas.

— happybuddha
fuente

2

meta bit: la razón por la que nadie respondió fue porque las extensiones a las preguntas existentes realmente no son buenas para las preguntas. Cosas como 'Actualizar' y 'Editar' son signos de una pregunta progresiva (¿qué pasa si la pregunta progresiva es un duplicado? O si alguien responde la actualización pero no el original? O el original pero no la actualización? - preguntas de seguimiento en nuevas preguntas es la mejor política)

Cada cadena de solo lectura que se usa más de una vez puede guardarse en un campo final estático, solo para evitar errores de tipeo o para refactorizar. Para los literales que solo se usan una vez, creo que realmente no importa.

— Trilarion

21

En tiempo de ejecución, no hace la diferencia.

El punto es la legibilidad: como variable miembro, es probable que se declare al comienzo del código fuente de la clase, y hacerlo estático significa que no tiene que asignarse para cada nueva instancia de la clase.

Hacerlo final significa para el lector que el valor no cambiará (también para el compilador, pero eso es menos importante aquí).

De esta manera, no hay "valores mágicos" escondidos en la implementación, y si se desea un cambio a la "constante", solo necesita cambiarse en un lugar.

Esto básicamente imita lo que haría un programador en C con un #define.

— GreyBeardedGeek
fuente

2

+1 la ganancia de rendimiento es irrelevante, se trata de legibilidad, mantenibilidad e intención.

— favor el

5

`final` ¡Los campos tienen muchos beneficios!

Declarar los campos como finaltiene valiosos beneficios de documentación para los desarrolladores que desean usar o extender su clase, no solo ayuda a explicar cómo funciona la clase, sino que también cuenta con la ayuda del compilador para hacer cumplir sus decisiones de diseño. A diferencia de los finalmétodos, declarar un campo final ayuda al optimizador a tomar mejores decisiones de optimización , porque si el compilador sabe que el valor del campo no cambiará, puede almacenar en caché el valor de forma segura en un registro . finalLos campos también proporcionan un nivel adicional de seguridad al hacer que el compilador haga cumplir que un campo es de solo lectura.

No intente utilizarlo finalcomo herramienta de gestión del rendimiento. Hay formas mucho mejores y menos restrictivas para mejorar el rendimiento de su programa. Úselo finaldonde refleje la semántica fundamental de su programa: para indicar que las clases están destinadas a ser inmutables o que los campos están destinados a ser de solo lectura.

Antes de declarar los campos finales, debe preguntarse: ¿este campo realmente necesita ser mutable?

— Anton Dozortsev
fuente

¿Por qué declarar una cadena (como final) y luego usarla?

final ¡Los campos tienen muchos beneficios!

`final` ¡Los campos tienen muchos beneficios!