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

[le y@m's]

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..

C'est sûr que les chances ne sont pas élevées, mais bon ça peut arriver ^^.
Et puis conceptuellement une constante est bien unique, donc avoir deux déclarations pour une même constante je trouve ça bizarre .

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 ?

C'est le comportement par défaut, cependant il est tout à fait possible de redéfinir la méthode toString(). Le nom utilisé lors de la création reste tout de même accessible par la méthode name() .

[bouye]

Je ne suis pas sur qu'une enum soit tout a fait adaptee a ce genre de choses entre autre car on a pas forcement besoin de stocker des choses d'un meme type (quoique... ) mais une interface ne l'est certainement pas au niveau de la conception objet (fut un temps j'avais un lien vers un tres bon article en anglais qui expliquait pourquoi). Bref, si tes constantes (String ou autres) doivent vraiment etre decrite dans une classe a part, tu fait une classe finale avec un constructeur private.

Pareillement cela fait des annees que j'ai defini les noms de mes proprietes dans des constantes (dans le composant lui-meme) et ce car ayant ete "traumatise" par cette foultitute de proprietes des composants Swings dont on ne peut a priori pas connaitre le nom a moins d'aller fouiller dans leur code source ou d'installer un PropertyChangeListener generique et de "sniffer" tous les changements de propriete qui interviennent lors de leur usage. A priori je ne m'en porte pas plus mal.

[bulbo]

Pour la classe finale avec constructeur private, c'etait bien mon intention de toute façon.

Par contre vous, vous feriez un import static de la classe ou vous feriez a chaque fois ClasseFinale.MyEnum.Nom.toString() ?

Bulbo

[le y@m's]

Je ne suis pas sur qu'une enum soit tout a fait adaptee a ce genre de choses entre autre car on a pas forcement besoin de stocker des choses d'un meme type (quoique... )

Ben en fait l'enum représente en quelque sorte le type "propriété". Utiliser une classe finale dédiée ou une enum me paraît revenir à peut près au même si ce n'est que l'enum me paraît plus "propre" (j'avoue que cela est quelque peu subjectif ^^).

Par contre vous, vous feriez un import static de la classe ou vous feriez a chaque fois ClasseFinale.MyEnum.Nom.toString() ?

Pourquoi utiliser une classe finale ET une enum ? c'est soit l'un soit l'autre non ?
MaClasse.MA_PROPRIETE ou MonEnum.MA_PROPRIETE.toString()
Pour l'import static, personnellement je ne l'utilise que si les propriétés apparaissent souvent .

[bulbo]

Ben en fait l'enum représente en quelque sorte le type "propriété". Utiliser une classe finale dédiée ou une enum me paraît revenir à peut près au même si ce n'est que l'enum me paraît plus "propre" (j'avoue que cela est quelque peu subjectif ^^).


Pourquoi utiliser une classe finale ET une enum ? c'est soit l'un soit l'autre non ?
MaClasse.MA_PROPRIETE ou MonEnum.MA_PROPRIETE.toString()
Pour l'import static, personnellement je ne l'utilise que si les propriétés apparaissent souvent .

En fait je veux regrouper les différentes catégories de constantes (enum) dans un seul fichier source clairement identifiable, d'ou la classe finale contenant les différentes enum.

Comme effectivement j'utilise pas mal de propriétés dans mon projet, je fais un import static. Mais l'écriture avec les enum fait que cela reste bien propre et lisible dans le code finalement.

De toute façon il faut bien reconnaitre que c'est dans 90% des cas de l'enculage de mouche ce que je fais la. En général quand une chaine est utilisée plus de 2 fois, c'est d'office une constante, si j'ai seulement un getter et un setter qui l'utilise je mets direct la constante chaine.

Je sens bien qu'après ça il va me gonfler pour y mettre même les messages des dialogues ou autre.. et la on y perd franchement car pour identifier d'ou vient un message faut trouver la constante et ensuite trouver ou est utilisé la constante. Une indirection de plus et inutile en plus quand on ne fait pas de localisation de l'appli.

En tout cas merci pour vos avis, je pense tenir un truc propre ET qui satisfera mon chef de projet, c'est déjà pas mal

Bulbo