Properties y clases de constantes

[Xerelo]

Veo mucho la utilización de una estructura que a mí no me acaba de convencer

Se crea una clase Configure que mediante un método static getPropiedad(propiedad) recupera la property buscada del fichero loquesea.properties.

prop.una = Hola
prop.dos = Mundo

La clase Constantes contiene una serie de constantes estáticas, cada una de ellas con la clave de una de las propiedades de loquesea.properties.

public static final String SALUDO = "prop.una"

Después, cuando se quiere recuperar una property desde un método cualquiera, se haría así.

String hello = Configure.getPropiedad(Constantes.SALUDO)

No sé por qué, pero a mí me parece más lógico en el archivo de constatntes recuperar ya las properties

public static final String SALUDO = Configure.getPropiedad("una.prop")

String hello = Constantes.SALUDO

¿Alguna opinión sobre cual es más recomendable u otras formas mejores de hacerlo?

[GreenEyed]

Los miembros de tipo static final se inicializan cuando la clase se carga en la JVM, así que para hacerlo como tú dices el objeto al que hace referencia Configure tendría que estar disponible en ese momento, lo cual seguramente implica cargar propiedades de un fichero en tiempo de carga de clases, en bloques estáticos de inicialización etc.

Personalmente no le veo el grave problema a la primera forma ya que a nivel "logico", lo que es constante es el nombre del parámetro pero el valor no es una constante, si no no se hubiera puesto en un fichero de propiedades externo para poder ser modificado. Así que tratarlo como una constante no me acaba de gustar.

Además, en el segundo caso se podría seguir accediendo al valor usando Configure.getPropiedad("una.prop") con lo que tendrías dos formas de acceder al mismo valor...

Es una opinión, pero no me parece ni más clara ni más eficiente la segunda forma.
S!

[Xerelo]

La pega que le veo yo, es a la hora de llamarlo

String hello = Configure.getPropiedad(Constantes.SALUDO)

vs

String hello = Constantes.SALUDO

Esta estructura la he visto en proyectos J2EE, y se utiliza para leer textos para mensajes, datos de configuración y valores constantes, por lo que no cambian durante la ejecución de la aplicación.

Gracias por tu opinión.

[GreenEyed]

No cambian durante la ejecucion, pero no son constantes. Las constantes "de verdad" el compilador las cambia por el valor a pelo durante el proceso de compilación y no cambian nunca. En este caso, son valores validos únicamente para ejecución.

¿La pega es tener que escribir unos cuantos caracteres mas? Por que tener que inicializar las propiedades en tiempo de carga de clases para no tener que escribir unos caracteres mas me parece mal cambio.

[Xerelo]

Quitando el hecho de que sí, soy vago y prefiero no hacer llamadas largas sobre todo si se repiten mucho en el código, hay otra cosa.

Cada vez que se ejecuta

Configure.getPropiedad(Constantes.SALUDO)

se hace una búsqueda de la propiedad entre todas las properties (no estoy seguro si queda en memoria o se lee cada vez del fichero), de la otra forma, esa búsqueda sólo se hace la primera vez que se accede a Constantes.

Pero vamos, que si una es tan utilizada supongo que será mejor, sólo quería comprender la razón.

Saludos

[GreenEyed]

Teniendo en cuenta que se almacenan en memoria y que hace una busqueda por hash y no "entre todas las properties", a no ser que tengas el código lleno de esas llamadas y se repitan dentro de bucles bastante grandes, no creo ni que pudieras medir la diferencia entre una aproximación u otra .

La razón básica para hacerlo así es que es mucho más sencillo de implementar(los inicializadores estáticos no se suelen recomendar mucho) y te podría permitir re-cargar las propiedades en caso de que se modifiquen durante una ejecución, según como implementes la clase Configure.
Por otro lado, queda mucho más claro que es un valor que se puede modificar y cual es la clave para acceder a el.
Yo si veo

String hello = Constantes.SALUDO;

pienso que estoy tratando con una constante y por lo tanto la asignación no tiene sentido, supongo que el valor ya es correcto etc.
Si veo

String hello = Configure.getPropiedad(Constantes.SALUDO)

Sé cual es el nombre por el que se guarda esa propiedad, sé que es "un input" y por tanto tengo que verificar si el valor es admisible, sé que existe la posibilidad de que cambie etc.

Claro que sabiendo de que va la cosa puedes averiguarlo, pero ya es una cosa más a tener en cuenta.

Esas son las razones que se me ocurren. Pero vamos, cada uno en su codigo hace lo que puede y le dejan, y como no creo que tenga que tocar tu código pues realmente me da igual . Sólo quería aclarar que ni por rendimiento, ni por claridad es mejor solución.

S!