2010-11-22 8 views
5

me metí en una discusión con un colega en relación con el problema siguiente:Decenas de métodos getter contra un único método get

Nuestro proyecto se lee en un archivo de configuración y almacena decenas de parámetros. Él ha almacenado estos datos en variables nombradas junto con docenas de métodos getter para cada variable. En mi opinión, esto ha hecho que la clase sea demasiado larga con los métodos getter y difícil de mantener.

private var; 

public String getVar() { 
return var; 
} 
// This appears dozens of times in the class 
...... 

Mi solución es almacenar pares de valores clave en un mapa, y tener un método único getValue (String key), que toma como argumento una clave que representa cada variable. Las claves se almacenarán como una lista de constantes en una clase Config que también manejará la lectura de los datos del archivo.

Config c = new Config(); 
c.readConfig(someFile); 
... 
c.getValue(Config.SOME_VAR); 

Su argumento en contra de mi diseño es que si cualquier necesidad clave para cambiar o hacerse obsoletos, todas las instancias de la clave tendrán que ser perseguidos y cambiado en muchos lugares en el código fuente, mientras que en su diseño todo se gestiona desde 1 archivo. Además, la seguridad de tipo plantea un problema, ya que Integer.parseInt() de una Cadena devuelta por getValue() puede fallar, mientras que en su método, el tipo de devolución es fijo.

¿Algún comentario al respecto? Gracias.

Respuesta

4

¿Qué es tan difícil de mantener acerca de esta solución? A menos que el formato de configuración cambie, no preveo ningún mantenimiento (aunque las sorpresas siempre son posibles). Si el mantenimiento es necesario, creo que esta solución lo hará más fácil, ya que todo el análisis relevante (incluido string-> int, etc.) está en un solo lugar.

Y tiene una comprobación mucho mejor en tiempo de compilación. Si elimina un método, el compilador le dirá. Si asigna el valor de retorno al tipo incorrecto, el compilador le dirá.

+1

Quizás sea solo yo ... No me gusta ver clases con más de 2000 líneas, la mitad de las cuales son solo getX() {return X;} – david

+4

Dos palabras: generación de código. – cdhowie

+3

Hay una diferencia entre larga y difícil de mantener. @cdhowie tiene razón. Dependiendo del formato de configuración, es posible que pueda ser la "fuente" real y generar el Java por completo. –

1

Es correcto suponer que, como está manteniendo los datos en los archivos de configuración, los valores de estas variables son fijos. Si es así, ¿no podrías usar ENUM?

public enum Data { 

RED("red"), 

WHITE("white"); 

private String color; 

    private Data(String color){ 
    this.color = color; 
    } 


    public String getColor(){return color;} 
} 

Incluso podría llegar a utilizar diferentes tipos de datos si intenta pensar un poco más en el diseño.

0

Tiendo a utilizar un marco como Apache Commons Configuration que proporciona acceso mecanografiado a las propiedades. Por ejemplo, si usted tiene una propiedad int puede utilizar:

int number = config.getInteger(INT_PROPERTY); 

debe definir todas las llaves en un lugar de modo que si usted decide cambiar la clave, es suficiente para cambiarlo en un solo lugar. Por ejemplo:

public static final String DB_PASSWORD = "db_connection_password"; 

Para obtener el uso de la propiedad:

String password = config.get(DB_PASSWORD); 

Si decide cambiar la clave para db_passwd, es suficiente para cambiar el valor de la constante de DB_PASSWORD. El resto de tu código permanece igual.

+0

Gracias, parece una forma más limpia de manejar la configuración. – david

Cuestiones relacionadas