[Javier Ader]

Buenas, planteo una idea para el futuro ya que no se si es realmente muy necesaria, aunque pienso que mejoraria la calidad “interna” del sistema. El tema viene por que cuando uno mira el código las “listas” terminan referenciadas nivel de clases PO como constantes (generadas una y otra vez por cada clase que tiene una referencia a una lista….); esto hace medio difícil la trazabilidad del uso de una determinada lista y en general deja el codigo bastante sospechoso al menos… En particular me tope con la necesidad de tener que crear otro tipo de tarjeta de credito; estas, por alguna razon fueron diseñadas usando listas (si uno modifica la lista tienen que regenerar todas las PO que la referencian……). Otro ejemplo un poco mas complicado es por ej, intentar agregar otro tipo de “displayType” (digamos un display de tipo búsqueda que funcione de manera distinta a la tradicional).
Otra mejora, es que pontencialmente, las clases que manejarían las listas podrian usarse como un medio de caching, en vez de tener que ir a la base de datos para cargarlas, por ej, en cada Lookup que las referencia (aunque esto ya no se si estan facil… el tema es que los lookups pueden tener filtros sql si mal no recuerdo….).

La idea es: por qué por cada lista no se crea un clase? Digamos RefXXXXXX donde XXXXX es el id, y dentro de la misma en enumerado, con un nombre fijo o el nombre de la lista en mayuscula por ej; creo que es la misma convencion que se una para los nombres de los prefijos de las constantes). Este enumerado o la clase que la contiene puede tener metodos para generar desde “strings” a enumerados y viceversa o para fácilmente determinar desde código (en particular desde código generado) si la una determinada string representa un elemento de la lista valido.

Medio al vuelo, un ejemplo podría ser:

Clase Ref10002.java (para la lista Colores, por decir algo)

Code:

public class Ref10002
{
public enum COLORES
{
//esta es la parte que realmente cambia de
//lista en lista; todo lo que sigue es genérico
/** este elemento del enumero podría tener un comentario
* tambien generado automáticamente */
AZUL (“AZ”),
BLANCO(“BLANCO”),
NEGRO(“NEGRO”);
//a partir de acá es código genérico

public final String cod ;
//este constructor podría ser publico…. lo que tiene
//de bueno que sea privado es que uno se asegura que el “==”
//funciona.
private COLORES(String cod)
{
this.cod = cod;

}
//para facilmente generar los inserts a base de datos
//@Override
public String toString()
{
return cod;
}

//metodo publico para obtener un Color desde un string
public static COLORES getFromCod(cod String)
{
//este codigo es generido
for (COLORES item: COLORES.values())
{
if (item.cod.equal(cod))
return item;
}
return null;
}

//determina si el codigo es valido
public static boolean isValidCod(String cod)
{
return getFromCod(cod) != null;
}

} //fin de enum Colores

//ACA podria venir codigo Helper a nivel de la clase Ref10002
//por ej, para manejar las traducciones de los elemetos, o
//para delegarle el acceso sql (y el posible caching) para la
//obtener ciertos elementos de la lista filtrados via sql
}

Una supuesta clase PO que tenga una referencia a Colores tendria simplemente un getters y setter del siguiente tipo

Code:

public class X_C_AlgoQueRerefenciaACOlores{
…..
public COLORES getColorEnum()
{
return COLORES.getFromCod(“la string cruda”);
}
public void setColorEnum(COLORES color)
{
//ACA no es necesrio el tipico “if color == x, etc etc”
//ya es un enumerado, asi que el codido debe ser siempre correcto
//tambien, aca se deberia chequera si color en null y
//si esto esta permitido, si no dispara una excepcion tal
//como lo hace el codigo actual
setStringCruda(color.cod);
}
….
}

Ok, hacer esto rompería a casi todas las clases que usan Strings; asi que pienso que tal vez lo mejor seria en todo caso permitir en el traspaso mantener las dos tipos de métodos (por eso a los métodos en la clase PO;pero marcando los que están usan String como “deprecated” (y que estos de todas maneras delegen a la clase RefXXXX la validación de los parámetros o la inicializacion de strings constantes).
Con este tipo de cosas uno puede facilmente encontrar todas las refencias a nivel de código a una lista determinada.

Después, cuando me haga un tiempo libre veo como se debería modificar el GenerateModel para manejar este tipo de cosas; por lo pronto les dejo la idea para ver que opinan.

[Autor]

Entradas