Discussion :

[Chavadam]

Au lieu de mettre en oeuvre une énumération correspondant à des valeurs de type 'int', en mettre une en oeuvre qui correspond à des valeurs de type 'boolean' et même de classe 'Boolean' car j'en ai besoin à plusieurs reprises dans une array 'Object' multi-dimensionnelle.
Donc au lieu de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
public class FormuleTarifaire
{
    enum Prix {indexés, fixes}   // 'int'
 
    final static public Object[] formuleTarifaire =
    {   new Object[]
        {   new String( "Fournisseur" ),
            new Integer(Prix.indexés)
        },
        new Object[]
        {   new String( "Région" ),
            new Object[]
    ...

plutôt

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
{
    enum Prix {indexés, fixes}  // Comment faire pour 'boolean'
 
    // Grande array pleine de Strings, Object, BigDecimal, (Boolean ?), ...
    final static public Object[] formuleTarifaire =
    {   new Object[]
        {   new String( "Fournisseur" ),
            new Boolean( (boolean) Prix.indexés)  // Ou qqch s'y rapprochant
        },
        new Object[]
        {   new String( "Région" ),
            new Object[]
    ...

J'ai un vague souvenir avoir vu cela quelque part de réalisé. Je rêve ?
Dans l'API, il existe un constructeur Boolean(boolean value)
N'est-ce pas d'intérêt presque général ?
Merci bcp.

[CyberChouan]

1) Ta structure objet est vraiment particulière... A mon avis, tu devrais en revoir la conception avant d'aller plus loin.

2) Pour ce que tu veux faire, pourquoi passer par un enum intermédiaire si au final tu veux un booléen ?

3) C'est cependant possible, mais en utilisant un constructeur dans ton énumération (note : les accents en programmation sont très déconseillés !)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
enum TypePrix {
   INDEXE(true),
   FIXE(false),
 
   boolean indexe;
 
   TypePrix(boolean indexe) {
      this.indexe = indexe;
   }
 
   boolean isIndexe() {
      return indexe;
   }
}

[gifffftane]

J'ai quelque mal à comprendre ta démarche, alors qu'elle semble pour toi quasi évidente.

J'ai l'impression que tu qualifies des valeurs qui vont par paire (indexé/fixe, donc), et que tu considères que l'une correspond à VRAI, l'autre à FAUX, d'où l'idée que ça correspond à un booléen.

Si tel est bien le cas, la meilleure approche à mon avis est de ne pas le transformer en booléen, mais de conserver partout sa valeur enum. Je ne vois pas pourquoi tu remplaces Prix.indexés par false ou true ; conserve Prix.indexés, c'est si bien ?

Peut être veux-tu le faire pour mémoriser quelque part la valeur de Prix dans un endroit qui n'accepte que les booleans ? Dans ce cas il y a mille combines, par ex :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
enum Prix
{
 indexé, fixe;
 
 public boolean enBooléen()
 {
  return this == indexé;
 }
 
 public static Prix deBooléen(boolean val)
 {
  return val ? indexé : fixe;
 }

Approximativement.

edit : mince, grilled by CyberChouan

[Chavadam]

Chers Gifffftane et CyberChouan,

Merci pour vos rapides réponses. Il semble que mon exposé original n'est pas bien en équilibre entre "Bref et rien que ce qui concerne ma question" et "Suffisamment d'explication pour que cela ne nécessite plus de question d'éclaircissement". Voici donc réponse à vos questions :

Mes arrays d'Object ("primaires"), pleines de new Object[], new BigDecimal(), new String() ... constituent une étape intermédiaire entre,
- d'une part, l'une des quelques listes de prix = données d'entrée (XML) de différents fournisseurs, reçues périodiquement et comportant des prix et intitulés d'articles de structure très peu uniforme (à plusieurs sous-structures) et dont la présence de certains éléments peut varier d'une période à l'autre,
- et d'autre part
--- un objet de classe TreeModel qui sert de référence à un objet de classe JTree (plein de 'Default MutableTreeNode's) créant un arbre permettant simplement de vérifier que ces données d'entrées sont introduites complètement et correctement,
--- ainsi qu'une autre array ("secondaire", à dimension non variable) où sont effectués un travail de réordonnancement et de regroupement des arrays primaires, afin que des boucles 'for' imbriquées trouvent facilement les valeurs.

La dimension de ces arrays d'Object[] primaires est variable, grâce aux créations de 'new Object[]' imbriqués. De plus, elle est très grande : plus de 200 éléments par période et par fournisseur. Ma classe de traitement, comportant l'array secondaire (= de regroupement) et les routines d'extraction de données (pour calculs et affichage graphique - boucles 'for' imbriquées) est prête.
Quelle autre structure plus simple qu'une array Object[] aurais-je pu mettre en oeuvre ?

Je voudrais simplement à présent ajouter à cette array, parmi les autres 'new XYZ', un 'new Boolean' mentionnant simplement 'Prix indexé ou fixe' (invariable par formule tarifaire d'un fournisseur et par période), selon ce qui est mentionné dans le fichier XML. La primitive 'boolean' n'est pas possible, n'étant pas un objet héritée de la classe Object, comme le sont BigDecimal, String et Boolean. Ma classe irait simplement lire la valeur de la propriété 'prix' de type boolean, dans l'objet de classe Boolean.
A cela, je cherche simplement à ce que les valeurs possibles de la propriété 'prix' de cette classe Boolean puisse comprende "indexé" et "fixe", qui est plus explicite que "false" et "true". D'accord qu'il s'agit d'une amélioration plutôt attirante ?

Mes intentions vous sont plus claires, à présent ?
Faut-il que je pense à la classe Enum<E extends Boolean<E>> ?

OK, je n'emploierai plus de caractères accentués. Je n'ai jamais eu de problème, développant toujours sous NetBeans (6.5). Pour ma connaissance : Quand pourrais-je rencontrer des problèmes ? Lorsque mon application est transportée dans un autre IDE (NetBeans 6.5), OS (Windows XP), JDK (1.6), JRE, API Swing ?

Merci de m'éclaircir ...

[b Oo]

Bonjour,
la réponse a déjà été donnée :

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
 
enum Prix {
   INDEXE(true),
   FIXE(false),
 
   boolean indexe;
 
   Prix(boolean indexe) {
      this.indexe = indexe;
   }
 
   boolean toBoolean() {
      return indexe;
   }
}
 
final static public Object[] formuleTarifaire =
{   new Object[]
    {   new String( "Fournisseur" ),
         new Boolean( Prix.INDEXE.toBoolean() )
    },
    new Object[]
    {   new String( "Région" ),
         new Object[]
 
…

[gifffftane]

Quelle autre structure plus simple qu'une array Object[] aurais-je pu mettre en oeuvre ?

Une classe que tu aurais créée, et qui exprime ce que tu comprends de ce que tu veux manipuler.

Je pense que le fait que tu utilises Object, qui ne veut rien dire, est une des raisons pour lesquelles nous avons tant de mal à te comprendre.

Je voudrais simplement à présent ajouter à cette array, parmi les autres 'new XYZ', un 'new Boolean' mentionnant simplement 'Prix indexé ou fixe' (invariable par formule tarifaire d'un fournisseur et par période), selon ce qui est mentionné dans le fichier XML. La primitive 'boolean' n'est pas possible, n'étant pas un objet héritée de la classe Object, comme le sont BigDecimal, String et Boolean. Ma classe irait simplement lire la valeur de la propriété 'prix' de type boolean, dans l'objet de classe Boolean.

Je ne vois toujours pas ce qui rend obligatoire le recours à un boolean, ni même à un Boolean : une énumération est de type Object ; tu peux affecter un Prix.INDEXE à une variable déclarée comme Object.

Et, pour ce qui est de rendre un boolean en Boolean, il vaut mieux utiliser Bolean.valueOf, surtout si tu le fais souvent.

OK, je n'emploierai plus de caractères accentués. Je n'ai jamais eu de problème, développant toujours sous NetBeans (6.5). Pour ma connaissance : Quand pourrais-je rencontrer des problèmes ? Lorsque mon application est transportée dans un autre IDE (NetBeans 6.5), OS (Windows XP), JDK (1.6), JRE, API Swing ?

Perso j'utilise les caractères accentués dans mes sources, car je parle français dans mes sources.

Je préfère ne pas faire de commentaires sur l'usage de l'anglais prétendu nécessaire, et quand j'intègre une nouvelle équipe je programme d'abord en anglais, car je sais que c'est considéré comme une marque de savoir-faire la plupart du temps, alors que programmer en français est considéré comme une grosse faute. Je deviens vieux, je ne me bats plus.

Avec les accents, quelques fois tu peux avoir des problèmes lorsque tu intègres dans tes logiciels des outils externes, et surtout lors des échanges de sources entre ordi qui n'ont pas le même encoding. Ne pas mettre d'accents est une simple façon de masquer le problème, pour le résoudre il suffit de spécifier un encoding pour le projet, cela n'a rien à voir avec les accents. Un accent UTF-8 sera correctement rendu sur tous les UTF-8.

De nos jours, il vaut mieux fuir outils et équipes qui ne savent pas gérer les encodings. Une équipe qui n'est pas rigoureuse de ce coté là aura tôt ou tard (et plutôt tard, malheureusement pour elle) des problèmes, qu'elle emploie des accents dans ses sources ou pas. Dès l'instant qu'elle sait traiter les encodings, les accents ne sont plus un problème.

Donc, au risque de contredire notre ami CyberChouan, je dirai OUI, utilise des accents, mais en te cachant

[Chavadam]

Remerciements sempiternels ...

[CyberChouan]

Donc, au risque de contredire notre ami CyberChouan, je dirai OUI, utilise des accents, mais en te cachant

Bon, on dévie de la discussion originelle mais je vais tout de même argumenter mon point de vue, avec un cas que j'ai réellement rencontré.

Sous Windows, Eclipe utilise par défaut l'encodage de fichier "cp1252".

J'ai eu à récupérer de telles sources pour travailler dessus sur un Eclipse, mais sous Linux. Les sources ne compilaient pas et étaient inexploitable, car les caractères accentués dans les sources ne passaient pas sous Linux.

Dans les commentaires des méthodes (et Javadoc), l'usage de français et d'accents ne me dérange pas. Pas plus d'ailleurs, lorsqu'on travaille avec des classes/méthodes fonctionnelles, les noms de variables/méthodes de type "calculerPrixTTC", etc. ne me choquent pas non plus.

Mais par contre, les caractères accentués dans le code source lui-même sont à éviter, car en fonction de l'encodage du fichier, les sources peuvent devenir enexploitables sur un autre système (vécu, cf. ci-dessus).

J'ajouterai que l'absence de caractères accentués dans les sources est une des règles vérifiées par les outils usuels de vérification de la qualité du code (CheckStyle, PMD, etc.)

[Djobird]

*se souvient d'un rendu de projet ou toute la promo avait passer des heures à supprimer les accents des commentaires car ils ne passaient pas sous une compilation via ant".

Après ca une moitier s'est juré de ne plus jamais utiliser d'accent, et l'autre a ne plus utiliser ant