Discussion :

[menzlitsh]

Salut tout le monde,
J'ai un ensemble de constante à déclarer pour l'utiliser dans mon apllication,
est-ce que je doi utiliser un interface comme

Code :

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

1
2
3
public Interface Constante{
public static final String CONSTANTEA ="moiMeme"; 
public static final String CONSTANTEB ="unAutre";

ou bien

Code :

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

1
2
3
4
Abstract class Constante{
public static final String CONSTANTEA ="moiMeme"; 
public static final String CONSTANTEB ="unAutre";
}

Laquelle je doit utiliser?
C'est quoi la différence en terme de performance et de point de vue BestPricteces?
Merci pour l'aide

[gifffftane]

Pour moi, la best practice est de ne pas utiliser de public static final Je les remplace toujours par des private static final.

Je pense que c'est mieux en java de réfléchir dans le cadre d'instances ; par exemple ici je mettrais à tout le moins objet.getConstanteA(), ou des enums, ou autre d'adapté. Et, surtout, englober le ou les traitements correspondant à cette constante dans la classe ; j'essaierai d'englober tous les traitements correspondants à constanteA dans une classe. (donc une instance).

Sinon pour ta question je pense que c'est l'approche par interface la meilleure, en tous cas la plus courante.

Je reproche à l'approche par public final static d'être peu robuste aux modifs, et d'être static.

Maintenant, le mieux étant l'ennemi du bien, cela m'arrive quelques fois de le faire quand j'ai pas envie de réfléchir.

[Vikisme]

Pour moi, la best practice est de ne pas utiliser de public static final Je les remplace toujours par des private static final.

Bah ça dépend de ce que tu veux faire... Exemple la constante JFrame.EXIT_ON_CLOSE elle est bien mieux en public que privée...

Je pense que c'est mieux en java de réfléchir dans le cadre d'instances ; par exemple ici je mettrais à tout le moins objet.getConstanteA(), ou des enums, ou autre d'adapté. Et, surtout, englober le ou les traitements correspondant à cette constante dans la classe ; j'essaierai d'englober tous les traitements correspondants à constanteA dans une classe. (donc une instance).

Bah je ne suis pas très d'accord, c'est bien certe de réflérir en termes d'objets, mais faut pas non plus en abusé. Faire une intance pour obtenir des constantes communes à une classe c'est pas forcément recommandé...

Je reproche à l'approche par public final static d'être peu robuste aux modifs, et d'être static.

Hum... C'est un peu le principe d'une constante d'être "static".

[fabszn]

Hello,

Pour moi, la best practice est de ne pas utiliser de public static final Je les remplace toujours par des private static final.

Heu , Dans le cas d'une classe regroupant des constantes, quel est l'interêt de créer une instance de classe ??
Je ne pense que ca soit une mauvaise pratique d'utiliser public final static
au contraire (voir l'exemple plus bas).

Si il doit y avoir un traitement sur des constantes.. (et encore) au mieux on va créer des méthodes statiques.

Effectivement, l'idéal est d'utiliser un type enum et si on n'est pas sous la version 5 (min) on peut construire soit même sa classe d'énumération :

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
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
96
97
98
public class CategoryEnum {
 
		public static final ArrayList listCats = new ArrayList();
		public static final CategoryEnum CONST1;
		public static final CategoryEnum CONST2;
 
 
 
		static
		{
			listCats.add(CONST1 = new CategoryEnum("const1","constante 1",1));
			listCats.add(CONST2 = new CategoryEnum("const2","constante 2",2));
 
 
		}
 
		private String name;
		private String title;
		private Integer idBD;
 
		protected CategoryEnum(String pName,String pTitle,Integer pIdDB)
		{	
			this.name = pName;
			this.title = pTitle;
			this.idBD = pIdDB;
		}
 
		public static List getCategories(){
			return listCats;
		}
 
		/**
                 * @return
                 * 
                 * return un objet de type Integer
                 */
		public Integer getIdBD() {
			return idBD;
		}
 
		/**
                 * @return
                 * 
                 * return un objet de type String
                 */
		public String getTitle() {
			return title;
		}
 
		/**
                 * @return
                 * 
                 * return un objet de type String
                 */
		public String getName() {
			return name;
		}
 
	/**
         * Permet de comparer deux categories, si le parametre est null on considere que la comparaison 
         * est fausse.
         */
	public boolean equals(Object obj) {
		if(obj ==  null){
			return false;
		}
		return new Integer(this.hashCode()).equals(new Integer(obj.hashCode()));
	}
 
	/* (non-Javadoc)
	 * @see java.lang.Object#hashCode()
	 */
	public int hashCode() {
 
		return (name + idBD + title).hashCode();
	}
 
 
	public static CategoryEnum getCategoryEnumByName(String catName){
 
		if(catName==null)
		{
			throw new NullPointerException("Le nom de la passé en parametre est null" );
		}
		for(Iterator i = listCats.iterator();i.hasNext();){
			CategoryEnum c = (CategoryEnum)i.next();
			int hc = c.getName().hashCode();
			if(hc == catName.hashCode())
			{
				return c;
			}
		}
		//cas ou la catégorie n'existe pas !
		return null;
	}
 
 
}

C'est un exemple..

[iohack]

Ma vision des choses à été très bien résumée par Rom

[gifffftane]

Eh bien je vais être extrême, puisque vous m'y poussez. Pour moi, une constante est l'indice d'une erreur, de quelque chose de mal vu, de mal compris. C'est une petite lampe jaune qui s'allume.

On me parle de l'EXIT_ON_CLOSE. Bien sûr que je l'utilise souvent. Mais j'observe que, lorsque un logiciel prend de l'ampleur, je dois toujours l'effacer des endroits où je l'avais mise au premier abord, pour la remplacer par une variable, ou quelque chose qui gère la fin, voire même quelque chose de complètement différent.

C'est que le contexte et la gestion du logiciel se précise mieux, tout en prenant de l'ampleur.

Cela peut être simplement que je teste ma fenêtre ; si je laisse l'EXIT_ON_CLOSE tel que, alors s'en est fini pour les tests suivants...

Cela peut être aussi que la fenêtre que je croyais toute seule au départ se multiplie, se clone ; si l'une d'elle fait l'exit du programme, évidemment, c'est mal barré pour les autres.

Et ainsi de suite.

[®om]

Si ce sont des constantes pour paramétrer ton application, une interface est suffisante... De plus ça t'évite le public static final, vu que c'est implicite dans une interface.

Si c'est pour des énumérations, il faut définir une enum plutôt que des constantes.

Par exemple,

Code :

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

enum Humeur { CONTENT, PAS_CONTENT, MOYEN }

[benwit]

En se basant sur ton titre (Difference entre Class Abstraite et interface), la différence, c'est qu'une interface ne définit aucun code d'implémentation. Les méthodes des interfaces sont également toujours publiques.

Pour définir des constantes, tu peux utiliser les enum à partir de java 5.

[Pill_S]

Les interfaces sont également toujours publiques.

Faux!

Les interfaces peuvent aussi être privées package....


Ce sont les méthodes qu'elles déclarent qui sont toujours "public abstract"

[benwit]

Oui, je pensais aux méthodes. Merci de corriger

[adiGuba]

Salut,

Les interfaces peuvent aussi être privées package....

D'ailleurs elles peuvent aussi être protected ou private... (si si je vous assure )

a++

[benwit]

ça m'a fait le même effet la fois où j'ai fait un new UneInterface() { ... } !