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.
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
Dos palabras: generación de código. – cdhowie
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. –