Discussion :

[electrovolt]

Bonjour,

Lors de mes devs professionnels, j'ai constaté sur différentes applications la même structure pour les fichiers constantes/.properties :

-Un fichier .properties du type
cle1="valeur1"
cle2="valeur2"
etc

-Un fichier de constantes qui contient les clé du fichier .properties
MA_CONSTANTE_1 = "cle1"
MA_CONSTANTE_2 = "cle2"
ect


1) Pourquoi procéder comme ceci (avantages/inconvénients) ?
2) Comment accéder aux valeurs du fichier .properties depuis les constantes (un appel à chaque fois au fichier .properties ?)


Merci pour vos éclaircissements

[thelvin]

1) Pourquoi procéder comme ceci (avantages/inconvénients) ?

Par exemple si on utilise cette constante à plus d'un endroit dans le code.
Avec une constante on limite les erreurs bêtes qui peuvent arriver en utilisant plusieurs fois la même String :

Le compilateur ne dira rien si on utilise "cle1" ici et "cle.1" là.
Le compilateur fera une erreur si on utilise MA_CONSTANTE_1 ici et MA_CONSTANTE1 là. Parce que MA_CONSTANTE1 n'existe pas. On s'est trompé en tapant MA_CONSTANTE_1.

Il y a aussi un côté "fascination" des développeurs devant les constantes. Les développeurs n'hésitent pas à modifier une String qu'ils trouvent ici ou là, s'ils pensent que ça aide.
Par contre, devant une constante "Attention, c'est une constante, pas toucher ! Plein de code dépendent de ça."

2) Comment accéder aux valeurs du fichier .properties depuis les constantes (un appel à chaque fois au fichier .properties ?)

Avec la classe Properties. Il faut en construire une, une fois, en faisant load() du fichier.

Ensuite, récupérer ce qui est dedans avec getProperty() :

Code :

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

String value1 = mesProperties.getProperty(MA_CONSTANTE_1);

[andry.aime]

Bonjour,

cle1="valeur1"

Attention, ces doubles quote seront aussi prises dans la valeur de cle1.

A+.

[ifsera]

Salut,

dans la même idée, il y a le ResourceBundle

Le ResourceBundle permet de gérer facilement la localisation d'une application en gérant de multiples sources (par exemple des fichiers properties différents pour chaque langue)

Le Properties permet d'obtenir des associations clef/valeur à partir d'un fichier texte.

[verbose]

La solution que je trouve la plus élégante consiste à stocker non pas les clés, mais les valeurs dans un fichier de constantes.

Je m'explique. La solution la plus courante est en effet d'avoir un fichier de properties clé/valeur, et une classe de constantes avec les clés admises.

Au lieu de ça, on garde toujours notre fichier de properties qui permet de configurer son application sans recompiler tout le projet, mais dans la classe de constantes, au lieu de lister les clés, on liste directement les valeurs :

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
 
public class Constantes {
    private static final String RESOURCE = "config.properties";
 
    static {
        Properties props = new Properties();
        props.load(Constantes.class.getClassLoader().getResourceAsStream(RESOURCE);
 
        PROPRIETE1 = props.getProperty("cle1");
        PROPRIETE2 = props.getProperty("cle2");
    }
 
    public static final String PROPRIETE1;
    public static final String PROPRIETE2;
}

Ainsi, le fichier de properties n'est lu qu'une seule fois, et la correspondance entre clé et valeur est garantie.

[Boojum]

Le fichier .properties n'est de toute façon lu qu'une seule fois, si tu conserves bien ton Properties ou ton ResourceBundle (recommandé, la lecture d'un fichier étant une opération longue).

Attention également, tes "constantes" n'en sont pas au sens Java du terme (mis à part RESOURCE) : en Java, une constante est un attribut static final initialisé par une valeur constante (à savoir, un String, une valeur numérique ou une autre constante). Elles sont traitées de manière spécifique par le compilateur (remplacement direct par leur valeur).

Cela étant, je suis d'accord sur le fond : autant que l'attribut stocke directement la valeur.