Est-il possible d'ajouter de nouvelles valeurs à un enum ?

Est-il possible d'ajouter de nouvelles valeurs à un enum ?
Je pensais faire une sous-enum qui apporterait de nouvelles valeurs, mais puisque ce n'est pas possible...

Mon idée est de travailler en couche: une application de base apportant son lot de valeur à mon enum Modules. Des applications spécialisés étendant l'application de base ammenant leurs propres valeurs à l'enum Modules.

ApplicationBase -- enum Modules { moduleB1, moduleB2, moduleB3 }
ApplicationSpécialisée extends ApplicationBase -- enum Modules { moduleB1, moduleB2, moduleB3, moduleS1, moduleS2 }

C'est possible quelque chose comme ça ?

Apparemment tu voudrais pouvoir créer un enum dérivé du premier qui définirait des valeurs en plus.
Le seul problème est que dériver en Java (et dans le monde objet en général) signifie héritage: ce qui n'est pas possible pour les types enum.
Par contre rien ne t'empêche de définir toutes les valeurs dont tu peux avoir besoin dans un seul enum, et ne les utiliser qu'au besoin (c'est une solution parmi beaucoup d'autres).

Merci pour ta réponse. Les pré-ajouter ne fonctionne pas, car mon principe de développement est l'empilement, où chaque brique hérite des briques précédentes tout en amenant de nouvelles fonctionnalités inconnues au moment où les briques précédentes sont construites.
Je vais voir si par réflection on pourrait modifier un Enum...

Salut,

Citation:

Envoyé par lvr

Je vais voir si par réflection on pourrait modifier un Enum...

Non !

Les enums ne sont pas faites pour cela ! Elles représentent un ensemble d'éléments fini.

Si tu as besoin de liste d'éléments variables, il te faut utiliser des Collections...

a++

Merci de briser mes espoirs ;) Je vais continuer avec mes "final static int". Ils marchent bien !

Il faudrait savoir ce que tu veux faire exactement avec cela... (ce n'est pas très clair je trouve).

a++

Ce que je voudrais faire c'est écrire ceci en mieux:

Code:

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
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
public class clModuleConstructor extends DefaultModuleConstructor {
 
    // définitions nécessaires pour le fonctionnement des modules spécifiques à Zweeger
    public final static int MODULEPIANO = 16;
    protected final static Class<? extends clModuleAbstract> MODULEPIANO_CLASS = clModulePiano.class;
 
    public final static int MODULEREMAPPER = 33;
    protected final static Class<? extends clModuleAbstract> MODULEREMAPPER_CLASS = clModuleRemapper.class;
 
    public final static int MODULEMIDIREMAPPER = 34;
    protected final static Class<? extends clModuleAbstract> MODULEMIDIREMAPPER_CLASS = clModuleMidiRemapper.class;
 
    private Class<? extends clModuleAbstract>[] moduleTypes = new Class[8];
    {
        moduleTypes[0] = MODULELFO_CLASS;
        moduleTypes[1] = MODULERND_CLASS;
        moduleTypes[2] = MODULEPIANO_CLASS;
        moduleTypes[3] = MODULEENVR_CLASS;
        moduleTypes[4] = MODULEENVCONST_CLASS;
        moduleTypes[5] = MODULEMIDIREMAPPER_CLASS;
        moduleTypes[6] = MODULEDELAY_CLASS;
        moduleTypes[7] = MODULEREMAPPER_CLASS;
    }
 
    /**
     * Constructor de base
     */
    public clModuleConstructor() {
        super();
    }
 
    /**
     * Retourne le super type qui correspond de la classe passée en entrée
     * @todo A supprimer lorsque le DefaultConstructor.SUperType(...) sera réécrit
     * @param type int
     * @return int
     */
    public int SuperType(Class moduleClass) throws GenericException {
        if (MODULEPIANO_CLASS.equals(moduleClass)) {
            return this.MODULEPIANOFAMILY;
        } else if ((MODULEREMAPPER_CLASS.equals(moduleClass)) || (MODULEMIDIREMAPPER_CLASS.equals(moduleClass))) {
            return this.MODULEDIVERSFAMILY;
        } else {
            return super.SuperType(moduleClass);
        }
    }
 
    /**
     * Fournit le nom de la classe qui correspond au type de module passé en entrée
     * @param type int
     * @return String
     * @throws IllegalArgumentException
     */
    public Class<? extends clModuleAbstract> getClassForType(int type) throws IllegalArgumentException {
 
        switch (type) {
        case MODULEPIANO:
            return MODULEPIANO_CLASS;
        case MODULEREMAPPER:
            return MODULEREMAPPER_CLASS;
        case MODULEMIDIREMAPPER:
            return MODULEMIDIREMAPPER_CLASS;
        default:
            return super.getClassForType(type);
        }
    }
 
    /**
     * Retourne une liste des types de modules utilisable dans Zweeger
     * @return Class[]
     */
    public Class<? extends clModuleAbstract>[] getAvailableModuleTypes() {
        return moduleTypes;
    }
 
 
    /**
     * Retourne le type ModulePanel à utiliser pour un type de module donné.
     * A priori, tous utilisent le clDefaultModulePanel (càd un Trigger optionnel, une liste de clParamAbstract,
     * et un Out).
     * @param module clAbstractModule
     * @return Class
     * @throws IllegalArgumentException
     */
    public Class<? extends itModulePanel> getClassModulePanel(clModuleAbstract module) throws IllegalArgumentException {
        if (module.Type() == MODULEMIDIREMAPPER) {
            return clModulePanelMidiRemapper.class;
        } else        if (module.Type() == MODULEREMAPPER) {
            return clModulePanelRemapper.class;
        } else {
            return super.getClassModulePanel(module);
        }
    }
 
}

L'application que je développe est composée de briques ("modules") que l'utilisateur agence comme il veut pour avoir le résultat qu'il veut (générateur de son, suivi d'un filtre, d'un deuxième filtre, puis d'un réducteur de volume, ...).

J'ai développée l'application en librairies:
- un noyau central qui apporte des modules de base
- des extensions suivant la finalités: une extension audio qui génère de l'audio, une extension midi qui génère du midi.

L'exemple ci-dessus est une classe qui permet de créer les modules d'une des deux extensions. Elle "extend" le constructeur de la partie centrale.

Chaque constructeur indique au monde extérieure les classes qu'il veut utiliser, leur donne un numéro (utilisé pour la sauvegarde) et précise comment les représenter graphiquement (quelle interface l'utilisateur aura pour chaque module).

Mon idée est d'utiliser un point centrale pour tout ce qui est la création des modules. Typiquement à la sauvegarde, je mémorise le type du module. Mon système me permet facilement de retomber sur une classe...
Ce système peut paraître bizarre et je pourrais peut-être utiliser une collection de classe, où chaque classe devra implémenter des méthodes static permettant de récupérer des infos de base sur sa nature.
Ce que je regrette c'est qu'il ne soit pas possible (via les interface) d'obliger des classes à implémenter des méthodes static.
....

Bon, rien qu'en écrivant tout ça, j'ai des idées pour faire mieux.... J'ai promis à ma femme d'arrêter d'être toutes la journée la-dessus, donc ce sera pour une prochaine fois :aie: Merci.