Discussion :

[bulbo]

Bonjour la compagnie,

Une petite question moins facile qu'elle n'en a l'air..

Voila, régulièrement dans un projet on utilise des constantes String, parfois elles ne sont utilisées qu'une fois et sont donc déclarées a l'endroit ou on les utilise et point final (genre la clé pour accéder a une propriété).

Récemment mon chef de projet qui s'ennuie (donc qui m'ennuie ) m'a demandé de déclarer toutes ces constantes String au début de la classe histoire qu'on les retrouve plus vite si on veut les changer.

Moi ça me pose de petits problèmes cette approche.

1 - C'est bien gentil de modifier rapidement une constante mais si on ne voit pas le code ou elle est utilisée c'est risqué, on pourrait modifier la mauvaise par accident ..

2 - si la chaine est utilisée dans 2 classes différentes on doit la définir dans les 2 classes, pas super cool, surtout qu'il faudra se rappeler de changer toutes les définitions de cette chaine dans toutes les classes.

J'aimerais savoir si vous connaissez de bonnes pratiques éprouvées pour ce genre de chose ?

Il y a bien la solution d'une interface contenant la déclaration de toutes les constantes, mais sur un gros projet c'est bien fouilli a la fin et pour savoir quelle constante correspond a quoi ..

Bulbo

[EIN-LESER]

C'est plus une question qu'une reponse que je me permets de te metre la mais

je vois pas bien le soucis (peut etre car je suis assez novice)
que tu declare ta constante au debut de ta classe ou la ou tu t'en sers, la ou les methodes pour les changer reste les memes non?

le seul truc c'est qu'il faut fair atention en ecrivant les methodes suivantes
pour bien changer la constante qu'il faut mais en metant en comentaire quelques explications pour les constantes a leur declaration sa devrais le faire je pense.

Encore une fois c plus une question qu'une reponse car je n'ai peut etre pas bien compris la problematique dans quel cas je te pris de m'excuser d'avence et d'avoir la gentillesse si tu a le temps de me l'explique un peux ^^

merci d'avence

[dinobogan]

Il faut faire bien attention à rester dans le paradigme objet. Faire une interface remplie de constante, c'est fonctionnel, pas objet. Une constante est le plus souvent associé à un état d'un objet précis. Elle aura donc sa place dans la classe de cet objet.

[bulbo]

Bon je vais illustrer par un exemple, ce sera plus clair:

Dans mon projet j'accède a différentes propriétés, les noms de ses propriétés sont des constantes chaines ("my.prop" par exemple) et mon chef me casse les pieds a vouloir que je mette des déclarations de chaines au début de la classe.

Ca ne change rien, pire je trouve ça dangereux, si une propriétés est utilisée dans deux classes, il y a de fortes chances que l'on pense a changer un fichier mais pas l'autre.

La je ne parle pas de paradygme objet, je parle d'une astuce intelligente qui permettrait d'avoir un code facilement maintenable et dont les constantes chaines seraient facilement accessible (pour que mon chef soit heureux).
Le tout c'est de gagner en qualité et en clarté.

Une interface ou une classe abstraite m'irait très bien. C'est juste que c'est un poil foutoir et a la fin c'est dur de s'y retrouver s'il y a beaucoup de constantes.

J'ai eu une idée (si si ca m'arrive) pour organiser ca, une classe/interface (peu importe je pense) contenant des enums qui serviraient de catégories pour les constantes.

Par exemple j'aurais une enum PropertyKeys avec une méthode getValue(). Pour accéder a la clé "application.log.file" par exemple je ferai

Code :

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

1
2
 
PropertyKeys.LOG_FILE.getValue();

Ouaip je sais ça complique un peu l'écriture mais on regroupe les constantes, ce que veux mon boss, moi je n'apprécie guère la technique, je reste persuadé qu'il vaut mieux réduire la distance entre la déclaration de la constante et son utilisation pour faciliter la lecture/maintenance de la chose..

Bulbo

[le y@m's]

Je pencherais également pour l'utilisation d'une enum. En effet, rien que le fait d'avoir la même constante déclarée dans deux classes différentes me paraît très gênant (pour les risques d'oubli que tu as mentionné en cas de modification de la valeur) .

je reste persuadé qu'il vaut mieux réduire la distance entre la déclaration de la constante et son utilisation pour faciliter la lecture/maintenance de la chose.

Je ne suis pas convaincu, principalement pour la raison de la "multi déclaration" qui est, à mon humble avis, beaucoup plus dangereuse et risquée tandis que la lecture/maintenance de la chose peut être facilitée avec des commentaires généreux.

Remarque : pour l'enum, tu peux redéfinir la méthode toString() plutôt que de créer une nouvelle méthode getValue() .

[bulbo]

Pour les risques d'oubli:

1 - quel est l'intérêt de modifier le nom d'une clé existante ? Donc les chances que ça se produise un jour ...

2 - Si je dois changer une clé, dans mon IDE préféré je fais un find et zou..

Pour la méthode toString() j'y ai pensé, il ne risque pas d'y avoir un effet pernicieux vu que normalement cela retourne le nom utilisé lors de la création de la valeur de l'enum ?

Bulbo