2012-01-18 10 views
9

Tengo muchas clases con campos finales estáticos que se utilizan como valores predeterminados o configuración. ¿Cuál es el mejor enfoque para crear un archivo de configuración global? ¿Debo mover estos campos a una sola clase estática, usar el archivo de propiedades o qué?Usar archivo de propiedades en lugar de variables estáticas finales

Editar: Necesito usar estos valores tanto en clases Java como en páginas xhtml. Los valores no dependen del entorno. Pude compilar el proyecto para establecer nuevos valores, no hay problema.

+1

Un singleton probablemente sería mejor que una clase estática pura; puedes combinar eso con un archivo de propiedades y probablemente sea el mejor enfoque. – Viruzzo

+0

los arrojaría en un archivo de propiedades ... esto es especialmente útil cuando se requiere la internacionalización. – mre

+1

¿Por qué querrías un archivo de configuración global? Si estas son constantes, no hay necesidad de externalizarlas en un archivo de propiedades. Y si estas constantes son utilizadas por la clase Foo, el mejor lugar para ellas es en la clase Foo. –

Respuesta

20

La respuesta depende ...

  • cosas Poner en archivos de propiedades si los valores cambian en función del entorno de ejecución (por ejemplo, la configuración de conexión de bases de datos, direcciones IP de servidores extranjeros), o que es probable que cambiar a menudo/pronto
  • prefieren usar enum a static final constantes siempre que sea posible (evitar "stringly escrito" código)
  • Encuentra una biblioteca existente que podría tener lo que quiere (por ejemplo, utilizar para convertir TimeUnit horas a segundos, en lugar de tener static final int SECONDS_IN_HOUR = 3600;)
  • Lo que queda (que afortunadamente no va a cambiar pronto), use public static final en la clase que tiene "más propiedad" sobre ellos
  • Evite las clases que tienen métodos estáticos que devuelven una constante: solo código inflado
1

Tanto los approches están bien:

  1. tener una clase estática con final requeridos campos.

  2. Tenga un singelton pero guárdelo de varios hilos apropiadamente.

  3. si es posible use enum sobre campos estáticos. De esta forma, puede agrupar campos relacionados entre sí.

Si se trata de valores de nivel de aplicación, preferiré static clase sobre singelton.

y, debe decidir si estos son valores de configuración o valores de configuración que difieren de vez en cuando.

1

Y, el archivo de propiedades siempre es preferible para la configuración. Hay varias formas de leerlo, una de ellas es apache commons-configuration.

Si las propiedades dependen del entorno, externalícelas (fuera del proyecto) y establezca la ruta a ellas (por ejemplo, con -Dconfig.location=..). Si no cambian según el entorno, simplemente coloque el archivo de propiedades en classpath.

Consulte this article sobre las propiedades dependientes del medio ambiente.

A continuación, puede tener un soporte para el staticProperties/Configuration/... objeto, o, si es posible, inyectar (si se utiliza un marco DI) los valores donde sea necesario.

0

Es bueno tenerlos en un solo lugar. ¿Archivo de propiedad o clase estática? El archivo de propiedad se debe usar, por ej. localización. Clase estática para, p. Constantes de cadena

1

En cuanto a mí, la principal diferencia entre los enfoques es la capacidad de cambiar los valores sin cambiar un código.

Con campos finales estáticos, debe volver a compilar las fuentes para usar valores nuevos. Con los archivos .properties, solo tiene que reiniciar una aplicación que puede realizar el administrador del sistema, etc.

Parece ser una cuestión de si debe ser modificable o no y si debería estar disponible para alguien excepto un desarrollador. (En cierto sentido, es una serie de preguntas que es "a cargo de" estos valores: desarrollador o administrador del sistema/usuario, etc.)

1

Mi enfoque favorito es el siguiente:

public class MyProperties { 
private static final String BUNDLE_NAME = "my.package.MyProperties"; //$NON-NLS-1$ 

private static final ResourceBundle RESOURCE_BUNDLE = ResourceBundle 
     .getBundle(BUNDLE_NAME); 


private MyProperties() { 
} 

public static long getLong(String key) { 
    String strValue = getString(key); 
    long result = -1; 
    try { 
     result = Long.parseLong(strValue); 
    } catch (Exception exc) { 
     logger.error(exc.getLocalizedMessage()); 
    } 
    return result; 
} 

public static int getInteger(String key) { 
    String strValue = getString(key); 
    int result = -1; 
    try { 
     result = Integer.parseInt(strValue); 
    } catch (Exception exc) { 
     logger.error(exc.getLocalizedMessage()); 
    } 
    return result; 
} 

public static String getString(String key) { 
    String returnValue = System.getProperty(key); 
    if(returnValue != null && returnValue.length() > 0) { 
     if(logger.isDebugEnabled()) { 
      logger.debug(key+" assigned by system property"); 
     } 
     return returnValue; 
    } 
    try { 
     returnValue = RESOURCE_BUNDLE.getString(key); 
    } catch (MissingResourceException e) { 
     returnValue = '!' + key + '!'; 
    } 
    return returnValue; 
} 
} 

Esta clase simple primera búsqueda la clave en las propiedades del sistema luego en el paquete de recursos. Esto significa que puede anular la configuración de propiedad con las opciones de línea de comando -Dkey = value.