Discussion :

[Ivelios]

Bonjour à tous,
Pour le jeu que je développe actuellement, je suis confronté à un choix et j'aimerais avoir vos avis.

J'ai plusieurs double (constant) représentant des vitesses. Je les utilises dans 2 classes.
J'aimerais savoir si ça fait "propre" de créer un classe "Constante" et des mettre ces vitesses en public static final?
Pour ensuite les appeler comme ça : Constante.vAir
Ou alors les mettre dans une des 2 classes qui les utilises et faire des accesseurs?

J'ai le même dilemme avec des enum (pas constant pour le coup).
Merci

[adiGuba]

Salut,


S'il s'agit de valeur constante (qui ne devrait jamais être modifié), alors tu peux utiliser les public static final.

Si ces valeurs peuvent être modifier il est préférable de passer par un accesseur.

a++

[Ivelios]

Merci adiGuba, j'ai juste modifié mon post concernant les enum qui ne sont pas constant (enfin je ne croit pas )

Code :

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

enum ETAT { EAU, GLACE, TREMPLIN, TERRE, AIREAU, AIRGLACE, AIRTREMPLIN, AIRTERRE };

[thelvin]

Toutefois en général on n'aime pas trop créer des nouvelles classes juste pour leur mettre une liste de constantes.

L'usage est plutôt de définir ces constantes dans une classe ou une interface qui a déjà un rapport avec elles.

Edit : Je comprends pas trop la question avec les enums. Un enum c'est plus qu'une simple liste de constantes, c'est un type de données qui ne peut avoir que les valeurs qui y sont définies, ou null.

[Ivelios]

Edit : Je comprends pas trop la question avec les enums. Un enum c'est plus qu'une simple liste de constantes, c'est un type de données qui ne peut avoir que les valeurs qui y sont définies, ou null.

C'est la première fois que j'utilise des enum alors j'ai un peu de mal à comprendre "vraiment" ce que s'est.

Ma classe joueur à une instance de l'enum Etat. Actuellement enum Etat est définie dans ma classe joueur.
J'utilise un accesseur pour récupérer l'état du joueur.

Code :

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

1
2
3
4
5
6
7
8
public class Joueur implements IDrawable{
 
    public enum ETAT { EAU, GLACE, TREMPLIN, TERRE, AIREAU, AIRGLACE, AIRTREMPLIN, AIRTERRE };
 
    private ETAT etat;
 
    public ETAT getEtat(){return etat;}
    public void setEtat( ETAT etat ) { this.etat = etat; }

Je me demandais si je pouvais mettre enum Etat dans la classe Constante? en static ou static final?

[thelvin]

Ma classe joueur à une instance de l'enum Etat.

Bien. On préférera dire qu'elle a une variable du type enum Etat. Parce que, si un type enum a 7 valeurs possibles par exemple, chacune de ces valeur est l'une des 7 uniques instance du type enum en question, pour toute la JVM.

Actuellement enum Etat est définie dans ma classe joueur.

Bien. Tu peux aussi le mettre directement dans un fichier Etat.java

J'utilise un accesseur pour récupérer l'état du joueur.

Bien.

Je me demandais si je pouvais mettre enum Etat dans la classe Constante? en static ou static final?

Comme je l'ai dit, cette classe Constante n'est pas censée exister, donc non. Mais le langage ne l'interdit pas.

Pour info, un enum est toujours static final, que tu le dises ou non.

[Ivelios]

OK très bien, merci pour toutes ces informations.

Choix final : mettre les constantes dans IDrawable ou modifier IDrawable en ADrawable (classe abstraite) et mettre les constantes dedans.

Et pour l'enum, ce qui m'embêtais en le mettant dans la classe Joueur c'est ça :

Code :

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

if(j.getEtat() == Joueur.ETAT.GLACE){...}//j = instance de Joueur

C'est le "Joueur" qui me dérange... je trouve que ça fais tache.
Après c'est peu être mon esprit perverti qui tourne plus très rond

Tu peux aussi le mettre directement dans un fichier Etat.java

Je vais me pencher sur LA CHOSE. Voir si ça me plait esthétiquement parlant

Merci

[adiGuba]

Toutefois en général on n'aime pas trop créer des nouvelles classes juste pour leur mettre une liste de constantes.

Personnellement je ne trouve pas cela si dérangeant que cela...


@Ivelios : juste une remarque, les enums sont des classes et doivent respecter les mêmes conventions de nommages. ETAT devrait se nommer Etat :

Code :

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

public enum Etat { EAU, GLACE, TREMPLIN, TERRE, AIREAU, AIRGLACE, AIRTREMPLIN, AIRTERRE };

a++

[tchize_]

Toutefois en général on n'aime pas trop créer des nouvelles classes juste pour leur mettre une liste de constantes.

L'usage est plutôt de définir ces constantes dans une classe ou une interface qui a déjà un rapport avec elles.

Je me permet un bémol quand même. en général, un bon endroit c'est aussi dans une interface dont héritent une grande partie de ceux qui en ont besoin (cf l'api SWING qui fait régulièrement usage de cette technique)

[tchize_]

Code :

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

if(j.getEtat() == Joueur.ETAT.GLACE){...}//j = instance de Joueur

C'est le "Joueur" qui me dérange... je trouve que ça fais tache.
Après c'est peu être mon esprit perverti qui tourne plus très rond

deuxd possibiltiés

1) faire de etat une classe à part entiètre, et non pas une inner class de Joueur.
2) faire dans le code un

Code :

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

import static my.package.Joueur.*;

histoire de rameuter toutes les constantes dans l'espace de nommage local

[adiGuba]

Je me permet un bémol quand même. en général, un bon endroit c'est aussi dans une interface dont héritent une grande partie de ceux qui en ont besoin (cf l'api SWING qui fait régulièrement usage de cette technique)

Perso je n'aime pas trop cette technique. Au final ca devient assez brouillon et on n'arrive pas à déterminer l'origine exacte de la constante

Je préfère qu'une constante soit identifié de manière précise et unique

a++

[Ivelios]

Code :

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

import static my.package.Joueur.*;

histoire de rameuter toutes les constantes dans l'espace de nommage local

J'avoue, sur ce coup j'ai pas été fut-fut. J'ai même pas pensé à ça, c'est pourtant si simple

[Ivelios]

Je me permet un bémol quand même. en général, un bon endroit c'est aussi dans une interface dont héritent une grande partie de ceux qui en ont besoin (cf l'api SWING qui fait régulièrement usage de cette technique)

Perso je n'aime pas trop cette technique. Au final ca devient assez brouillon et on n'arrive pas à déterminer l'origine exacte de la constante

Je préfère qu'une constante soit identifié de manière précise et unique

2 solutions possibles donc .
Je vais voir la quel me parait la plus "cool"

pour info : je n'ai que 7 constantes en tout. Uniquement des doubles représentant des vitesses.
Donc pas la peine que je fasse un "gros gros truc".

[thelvin]

Perso je n'aime pas trop cette technique.

Chacun ses goûts, pas d'objection de ce côté.

Au final ca devient assez brouillon et on n'arrive pas à déterminer l'origine exacte de la constante

Hum. Ah bon ?

Je préfère qu'une constante soit identifié de manière précise et unique

Il faudrait vraiment faire de gros efforts d'obscurantisme pour parvenir à mettre en œuvre des constantes qui ne soient pas identifiées de manière précise et unique.

À peu près tout ce que je suis capable d'imaginer spontanément répond à ces critères.

[adiGuba]

@thelvin : le problème c'est que la même constante peut être accéder de manière différente.

Par exemple pour SwingConstants.CENTER, on peut utiliser JLabel.CENTER, JTextField.CENTER, JButton.CENTER, JTabbedPane.Button, ...

Bon après c'est sûr ce n'est pas la mort non plus

a++

[OButterlin]

D'un autre côté, l'interface représentant un "contrat", sa vocation n'est pas particulièrement d'avoir des valeurs.
Personnellement, je préfère une classe indépendante contenant des constantes (ou propriétés static) à usage commun et la définition des constantes (ou propriétés static) à usage "local" dans la classe qu'elles qualifient.
Mais rien n'interdit de faire autrement...