Discussion :

[rozwel]

Bonjour tout le monde,

J'ai un problème pûrement algorithmique assez gênant et délicat que je voudrais soumettre à votre sagacité.

Je travaille sur une application J2EE dans laquelle tous les types énumérés sont stockés dans la base de données. Autrement dit, en fonction du type énuméré, certains ont leurs propres tables avec un code et un texte dans toutes les langues, tandis que d'autres sont stockés dans une table générique avec une colonne pour identifier le type, et un lien vers une autre table qui contient les textes dans toutes les langues.

Par exemple, le type enuméré exprimé en Java5 comme suit:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
 
public enum PrinterType{
  LASER(new String[][]{
    {"fr", "Imprimante laser"},
    {"en", "Laser Printer"}
  }),
  BUBBLE_JET(new String[][]{
    {"fr", "Imprimante à jet d'encre"},
    {"en","Bubble jet printer"}
  }),
  SUBLIMATION(new String[][]{
    {"fr", "Imprimante à sublimation thermique"},
    {"en", "Thermal sublimation printer"}
  });
 
  private Map<String, String> texts;
 
  private PrinterType(String[][] texts){
    texts = new HashMap<String, String>();
    for(String[] text : texts){
      texts.put(text[0], text[1]);
    }
  }
 
  public getText(String language){
    return texts.get(language);
  }
}

Va pouvoir être représentée dans la table générique TYPE sous la forme suivante:
- family='PRN_TYPE', code='LASER', text='1'
- family='PRN_TYPE', code='BUBBLE_JET', text='2'
- family='PRN_TYPE', code='SUBLIMATION', text='3'

Et dans la table TYPE_TEXT:
- textid='1', language='fr', text='Imprimante laser'
- textid='2', language='en', text='Laser Printer'
-...

Et bien sûr, l'utilisateur veut pouvoir modifier les caractéristiques de ces types énumérés en passant par la base sans avoir à toucher au code, ce qui rend l'approche type-safe enum prise en exemple complètement impensable. En fait, ni la liste des valeurs possibles pour un type, ni les textes associés à chacune des valeurs ne doit être hard-codée.

Ma question est la suivante: est-ce que vous connaisser un design pattern ou un concept qui permet d'implémenter ce genre de choses en assurant un minimum de contrôle de type, tout en gardant la possibilité d'initialiser la liste des valeurs possibles et tous les attributs associés au moment de l'exécution du programme.

Je suis sûr qu'il existe un moyen en faisant joujou avec les Generics mais pour l'instant je sèche un peu.

Des suggestions?

[professeur shadoko]

première question: est ce que tes types d'imprimantes sont susceptible de varier souvent?
en d'autre termes est ce que tu peux te contenter d'avoir un énuméré simple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
enum PrintAgents {
    BUBBLE_GUM, LASER, SERGENT_MAJOR ;
}

ensuite tu peux t'en sortir de différentes manières
simpliste: un EnumMap dont les valeurs sont un Properties langue=message
plus politiquement correct serait une implantation de resourceBundle mais seule version 1.6 permettra de faire ça plus cool (je dis ça de mémoire)

[rozwel]

Non justement c'est mon problème, je ne peux pas hardcoder ça comme ça parce que les utilisateurs veulent garder cette flexibilité de pouvoir modifier les types énumérés uniquement par la base de données.

Par contre EnumMap effectivement je viens de voir ça dans l'API, je ne vois pas encore comment l'utiliser mais je vais fouiller. Si quelqu'un a un exemple, ce sera bienvenu.

[professeur shadoko]

Non justement c'est mon problème, je ne peux pas hardcoder ça comme ça parce que les utilisateurs veulent garder cette flexibilité de pouvoir modifier les types énumérés uniquement par la base de données.

donc c'est pas un énuméré.
mais tu peux avoir une Hashmap<String, Properties> indexé par ton type imprimante et construite en bloc static.

[natha]

donc c'est pas un énuméré.

Bien sûr que si. L'enum te garanti des objets type-safe, mais ne t'empêche absolument pas d'adjoindre des propriétés spécifiques et dynamiques tant qu'il n'y a pas d'ajout/suppression de type ou de modification de leur nom.

[rozwel]

J'ai déjà pensé à la solution de natha, mais même là l'utilisateur râle parce qu'on enlève la moitié de la flexibilité: la liste des valeurs possibles est hardcodée.

J'ai aussi utilisé une approche à base de HashMap mais après mon problème c'est le type-safety.

[professeur shadoko]

ah que pas d'acc.
je ne parle pas des propriétés de l'objet, je parle du fait qu'avec un énuméré on a une liste finie d'objet au compile-time.
donc ma question est peut être mal posée: peut-on rajouter dynamiquement d'autre imprimantes? j'avais compris que oui -> donc pas énuméré

[natha]

Alors nous on fait ça dans la boîte.

On a des codes systèmes qui sont en base de données et pour lesquels on créée l'ENUM correspondante (les utilisateurs ne peuvent pas insérer de nouvelles entrées).

On a une classe Code qui contient les propriétés de chaque objet de ce type (code, langue, nom entre autre)

Dans nos enum on fait bêtement :

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
enum MonType {
 
    TOTO,
    TATA,
    TITI;
 
    Code m_code;
 
    Code getCode() {
        if (m_code == null) {
            loadCode();
        }
        return m_code;
    }
 
    void loadCode() {
        // récupération de l'objet en base de données
    }
 
}

Voilà brièvement. Est-ce que ça t'aide ?