Je voudrais savoir, d'après toutes vos expériences, qu'est-ce qui vous semble le plus adapté, le moins couteux en ressources, ... pour stocker les constantes. Le singleton ou bien stocker toute les constantes sous la forme "static" ?
Merci bieng

bin une constantes ca devrait etre statique il me semble. Dans Apache SOAP il y a un exemple de ce genre d'objet, voir l'objet Constants
 
A+

en performance : un bête static final int
 
mais je trouve nettement mieux d'utiliser des singletons...
ca a des tats de trucs pratique, genre la méthode toString, le fait de pouvior les utiliser en tant que clef dans une hashmap, etc ... et puis c'est plus objet

Ok merci , en plus g eu droit aux 2 big boss de Java
 

.....Ben, tes constantes, Benou, pkoi tu les met pas en (par exemple)  
 
static final Integer MAX=new Integer(3);
et
static final int MAX_VALUE = 3;
 
par exemple....Non?? enfin, je trouve ça plus "léger" que des singletons...Et tiens, une question comme ça, pour Benou, t'as un exemple d'un de tes singletons, pour voir?? Parce que comme ça m'est jamais venu à l'idée de faire comme ça (enfin, je crois, ou alors j'ai mal compris) et que ça peu être utile, ben ça m'intéresse!  
 
Et sinon, ce que je fais des fois, quand j'ai beaucoup de classes qui doivent accéder à mes constantes, et qu'il n'y a pas d'ambiguité sur leur signification (genre, au hasard, des ID de types de messages, pour un protocole) j'ai fait une interface ProtocolConstants, qui contient mes constantes.  
Quand j'ai besoin d'une constante dans une classe, je lui fait implémenter mon interface, et hop, j'accède directement à mes constantes...
 
Bon, je sais pas ce que vous aller en penser (mais ça m'intéresse, tiens, d'ailleurs, pour voir si je met complètement le nez dedans ou pas) mais c'est assez pratique.

je ne suis pas sur que d'un point de vue maintenabilité ca soit terrible terrible...
c'est quand même plus clair d'avoir une classe Constants et d'utiliser Constants.CONSTANTE que d'utiliser CONSTANT et de ne pas trop savoir d'où ca sort...
et niveau perf ca doit être moins bon non? faudrait tester pour voir, la taille en mémoire de l'objet doit être plus importante quand tu implémentes ton interface de constantes non?

En tout cas, il y a quand même un désavantage à utiliser des constantes sous formes "static final", c'est que je serai obligé de recompiler toutes les classes qui utilisent ces constantes si un jour je change leur valeur...  

dans tous les cas, c'est des static final que tu vas devoir utiliser hein !

Bah d'après ce que j'ai pu voir, si je crée un singleton avec les constantes non static, je ne dois pas tout recompiler vu kil y a un appel de mon objet singleton chaque fois que je demande une constante en runtime;
 par contre si je les met en "static final", les constantes seront remplacées à la compilation, il n'y a plus d'appel lors du run...

je voulais dire, un truc comme ca :  
 
ici par exemple, c'est des constantes sous forme de singleton avec une notion d'ordre!

 
L'avantage c'est que si demain tu veux ajouter des fonctionnalitées à cette constante, c'est facile alors que si tu l'a définit en tant que int, tu devra faire une classe avec plein de méthode static utilitaire ce qui pas cool.
 
Autre intérêt, comme je le disais, c'est que tu peux l'utiliser directement avec les classes utilisant l'algo de hashage (HashMap, HashSet, etc ...).

ouais et ca ca arrache, je l'ai utilisé pour pas mal de truc au taf et ca rend le code assez lisible finalement

Ah ouais, je vois!!  
Ouais, c'est pas mal, effectivement, comme truc!!
 
Mais bon, faut dire aussi que ce que je pose comme constantes, ce sont à 99% des trucs qui ne sont pas destinés à changer : le timeout par défaut d'une socket ou d'une connection DB, le port par défaut d'un service (genre 21 pour ftp)...
Même pour les Ids de messages de mon protocole, en fait, j'ai des constantes, mais que je n'utilise qu'en "cas d'urgence" : en fait, la correspondance ID/Classe est en conf (base ou fichier) et les constantes ne sont utilisées que si la conf ne peut pas être lue, non sans avoir loggé un affreux truc pas cool dans le log d'erreur!!
 
Mais bon, sinon, c'est vrai que des static final, en dehors de cas du style DEFAULT_FTP_PORT=21, j'en utilise pas....Je fais des singletons, effectivement, mais il m'était jamais venu à l'esprit qu'en fait, je faisait des constantes avec sans le savoir...
 
Je suis le Monsieur Jourdain de la constante dans un singleton, c'est bô!

en fait mon truc, c'est plus pour faire des énumérations ...

euh ouais
arretez moi si je dis une connerie mais un
public static final String pouet = new String("pouet" );
dans une classe quelconque...
c'est un singleton en fait nan

 
ben non puisque pouet.equals("pouet" )
 
un singleton ne doit être égale qu'à lui même ...
 

ha ouais.
mais bon
dans le cas ou la constante dont on a besoin n'est qu'un String ou un int ou autre.... ok, c pas un *vrai* singleton, mais on s'en tape nan?

 
Le singleton pattern est utilise lorsqu'on veut avoir une seule *instance* d'un objet, pas forcement une seule *valeur*. L'exemple qu'a donne benou n'est pas un singleton car on a plusieurs instances de la classe AlertLevel.
 
Un squelette d'implem de singleton pattern donnerait :
 

 
Le singleton pattern n'est absolument pas pense pour l'implementation de constantes, mais pour assurer qu'une seule instance va exister.
 
Par contre passer par des objets par rapport a des types primitifs presente l'avantage de permettre d'utiliser toute la puissance de la POO.
 
A+
 

euh je pense que benou et moi savions tous les deux ce qu'est un singleton
perso j'avais pas maté le code de benou en détails, et pour mon histoire de String static je me suis un peu pissé dessus, mais en meme temps, il n'y a qu'une instance de cette String là. Mais forcément, la methode equals de String etant ce qu'elle est...
 
bref de toutes façons, ne fut-ce que pour la bonne synthese

ps: en general la methode statique on l'appelle getInstance()
en tous cas moi je prefere

 
+1

 
Ben oui, mais en l'occurence, pouet est la même instance que "pouet", grâce au système de mise en cache des chaines de caractères, non !? Dans ce cas particulier, c donc bien un singleton.

 
Edit : je ne suis toujours pas reveille donc j'efface les conneries que j'ecris...
 
Tout a fait, il etait tard, je venais de rentrer d'un voyage pour le boulot, j'ai presque pas dormi, depuis 1 semaine c'est la folie, demain je repars pour une conf d'une semaine en floride, j'ai un kick off de projet aujourd'hui, bref :
 
"j'ma sui tronpe"
 

non puisqu'il a fait appel explicitement au constructeur de String. Le constructeur construit forcément unn nouvel objet =>
 
pouet != "pouet"
mais pouet.equals("pouet" )
 

 
Mouais... et, donc, selon toi, quand j'écris, dans une classe "MaClasse" :
public static final MON_POUET = "pouet";
Si, n'importe où ailleurs, j'utilise une chaine de caractère "pouet", cette chaine ne sera pas la même instance que MON_POUET ? Pourquoi MON_POUET ne serait pas bufferisé ?
Par exemple pour faire :
assert (MaClasse.MON_POUET.equals ("pouet" ));
l'assertion est bonne là, non ?
 
EDIT : autant pour moi, ce que je dis là doit être vrai, mais n'est pas en contradiction avec ce que tu dis juste au dessus, j'avais mal lu . Appelle explicite au constructeur, bien sur. Tu t'en tires bien ! (j't'aurais un jour !)

quand tu veux gringo !
 
 
 
edit : merde, marche pas le lien

 

 
 
?

 
cé t'oune Gringo !

c'est ca le problème, l'image existe plus : y a plsu que google qui la connait mais le tag img ne reconnait pas l'url :'(
http://images.google.fr/images?q=t [...] rtrait.jpg