Proposer des options (fichier properties ?)

Version imprimable

Bonjour,

Je cherche à proposer différentes options pour l’exécution d’un programme. Pour simplifier mettons qu’il s’agit de 3 manières (manière 1, manière 2, manière 3) de faire un calcul.

Pour le moment je fonctionne comme cela :

J’ai une énumération qui défini les manières disponibles :

Code:

public enum ManieresDeCalcul {MANIERE_1, MANIERE_2, MANIERE_3}

Et dans ma classe principale j’ai une fonction calcule() qui attend la manière comme paramètre. Dans cette méthode, à l’aide d’un switch, j’utilise la méthode qui me convient :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 public int calcule(ManieresDeCalcul maniere) { int resultat; resultat = 0; switch(maniere) { case MANIERE_1 : //code pour la maniere de calcul 1 => resultat break; case MANIERE_2 : //code pour la maniere de calcul 2 break; case MANIERE_3 : //code pour la maniere de calcul 3 break; } return resultat; }
Première question : s’agit t’il d’une bonne méthode pour résoudre ce type de problème ou y a t’il d’autre moyen plus élégant ?

* * *

Ensuite, j’aimerais avoir la possibilité d’avoir un comportement par défaut. Il me semble que cela ne pose pas de problème, je n’ai qu’à avoir la même méthode sans paramètres :
Code:

1 2 3 public int calcule() { return calcule(ManieresDeCalcul.MANIERE_1); }
(en considérant que la MANIERE_1 est celle par défaut)

* * *

Maintenant je souhaiterais pouvoir définir quelle va être la méthode par défaut à utiliser (un fichier texte me semble assez approprié).

Il me semble que Java propose un mécanisme de fichier Properties pour répondre à ce type de problème.

S'agit il d'une bonne idée (sinon comment faire autrement) ?
Où puis je trouver un exemple, ou de la doc pour en savoir plus ?

Est-ce que dans le fichier properties je peux forcer le fait de devoir avoir une valeur contenue dans une énumération (ou faut-il que je refasse un mapping de type String -> Valeur de l’Enum)

Je voudrais utiliser une méthode standard et utilisée par tous, histoire d'éviter de réinventer une roue qui doit déjà exister en standard...

Merci

Autres solutions...
Commence par définir une interface de calcul que tu implémentes dans une classe séparée pour chaque manière de calcul:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
public interface ManiereDeCalcul {
	int calcul();
}
 
public class ManiereDeCalcul1 implements ManiereDeCalcul {
	public int calcul() {
		// TODO Premiere maniere de calcul
		return 1;
	}
}
 
public class ManiereDeCalcul2 implements ManiereDeCalcul {
	public int calcul() {
		// TODO 2e Premiere maniere de calcul
		return 2;
	}
}

Pour choisir le bon calcul en fonction de son nom tu peux utiliser une Map<String,ManiereDeCalcul> chargée statiquement...

Code:

1
2
3
4
5
6
7
8
9
import java.util.HashMap;
 
public class MapCalculs extends HashMap<String, ManiereDeCalcul>{
	public MapCalculs() {
		put("ManiereDeCalcul1",new ManiereDeCalcul1());
		put("ManiereDeCalcul2",new ManiereDeCalcul2());
		//...etc...
	}
}

Tu peux aussi utiliser ton propre ClassLoader...

Code:

1
2
3
4
5
6
7
8
9
10
11
12
 
public class CalculClassLoader extends ClassLoader {
	public ManiereDeCalcul getManiereDeCalcul(String maniere) throws ClassNotFoundException, InstantiationException, IllegalAccessException {
		Class<?> c=loadClass(maniere);
		return (ManiereDeCalcul)c.newInstance();
	}
}
public class Calcul {
	int calcul(String nom) throws ClassNotFoundException, InstantiationException, IllegalAccessException {
		return new CalculClassLoader().getManiereDeCalcul(nom).calcul();
	}
}

Cà donne ...

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public static void main(String[] args) {
	// Appels via une Map 
	MapCalculs mapCalculs=new MapCalculs();
	System.out.println(mapCalculs.get("ManiereDeCalcul1").calcul());
	System.out.println(mapCalculs.get("ManiereDeCalcul2").calcul());
 
	// Appels via un classLoader
	try {
		System.out.println(new Calcul().calcul("ManiereDeCalcul1"));
		System.out.println(new Calcul().calcul("ManiereDeCalcul2"));
	} catch (Exception e) {
		e.printStackTrace();
	} 
}

8O

En mille fois plus simple : les enum SONT des classes (spéciales, certes, mais des classes quand même).

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public enum ManieresDeCalcul {
  MANIERE_1 {
    public int calcul (String parametrePourCalcul) {
      return 1;
    }
  },
  MANIERE_2 {
    public int calcul (String parametrePourCalcul) {
      return 2;
    }
  },
  MANIERE_3 {
    public int calcul (String parametrePourCalcul) {
      return 3;
    }
  };
 
  public abstract int calcul (String parametrePourCalcul);
}

Et la méthode calcule (ManieresDeCalcul) :

Code:

1
2
3
4
public int calcule (ManieresDeCalcul mdc) {
  String monParam = "mon param";
  int resultat = mdc.calcul(monParam);
}

On en profite pour éviter un switch ET une surcharge de classes (même si implicitement, il y en a).

Je vois que c'etait pas une question si stupide...

Comment avec la méthode de dingoth, je peux stocker dans un fichier de paramétrage (a priori du texte) quelle doit être celle a utiliser par défaut ?

Est ce que là aussi il y un moyen de retrouver de quel élément de l'énumération on parle ?

J'imagine qu'il y a mieux que de faire :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 ManieresDeCalcul mdc; String mdcParDefaut; // on recherche (dans un fichier de config) la valeur par defaut -> mdcParDefaut if(mdcParDefaut.contentEquals("MANIERE_1")) { mdc = ManieresDeCalcul.MANIERE_1; } else if(mdcParDefaut.contentEquals("MANIERE_2")) { mdc = ManieresDeCalcul.MANIERE_2; } else if(mdcParDefaut.contentEquals("MANIERE_3")) { mdc = ManieresDeCalcul.MANIERE_3; } return mdc;
Merci pour vos réponses.

.

Certainement, il y a mieux, et toujours grâce aux enum !
Code:

1 2 3 4 5 6 ManieresDeCalcul mdc; String mdcParDefaut; // on recherche (dans un fichier de config) la valeur par defaut -> mdcParDefaut mdc = ManieresDeCalcul.valueOf(mdcParDefaut); return mdc;
Et paf, encore 5 lignes de parties !

15/12/2009, 15h10
hibour
dingoth je vois que vous apprécier énormément les enum :mrgreen:
Sinon à part les enum tu peux construire une application configurable à l'aide d'un fichier properties où
Code:

1 2 3 default=classe d'implémentation par défault maniere1=classe d'implémentation 1 maniere2=classe d'implémentation 2
Les classes d'implémentation doivent implémenter une certaine interface
Code:

1 2 3 public insterface IManiere { void calcul(Object param); }
Une classe Manager qui charge le properties et qui fait grosso modo
Code:

1 2 IManiere maniere = (IManiere) Class.forName(properties.get(maniere)); maniere.calcul(XXX);
15/12/2009, 15h48
dingoth

Bah, ma philosophie est : "utilisons les outils que nous avons à notre disposition". Les enum ont été introduites en Java 5, et malheureusement trop peu de développeurs savent tout ce qu'elles permettent.
16/12/2009, 11h10
jmini

Franchement j'adore ces Enum, je trouve ça très propre...

Un très grand merci à toi dingoth.
16/12/2009, 12h12
dingoth

De rien !

Notons toutefois que la méthode valueOf est très stricte : elle ne renverra une réponse que si le String donné est exactement (casse de caractère incluse) le nom programmatique de la variable. Donc si tu introduis ce nom dans un fichier properties, sois certain de ne pas refactoriser l'enum en changeant le nom de la variable.

Salut,

Citation:

Envoyé par dingoth

Notons toutefois que la méthode valueOf est très stricte : elle ne renverra une réponse que si le String donné est exactement (casse de caractère incluse) le nom programmatique de la variable. Donc si tu introduis ce nom dans un fichier properties, sois certain de ne pas refactoriser l'enum en changeant le nom de la variable.

Tu peux toujours proposer ta propre version un peu moins contraignante, et avec une valeur par défaut. Par exemple :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 public enum ManieresDeCalcul { // ... public abstract int calcul(String parametrePourCalcul); public static ManieresDeCalcul getByName(String name) { for (ManieresDeCalcul calcul : ManieresDeCalcul.values()) { if (calcul.name().equalsIgnoreCase(name)) { return calcul; } } return MANIERE_1; } }
Citation:

Envoyé par jmini

Franchement j'adore ces Enum, je trouve ça très propre...

En effet !

Mais il faut quand même garder en tête que du coup les méthodes de calcul sont limité, que tu ne peux pas donc en ajouter dynamiquement, et que tu ne peux pas avoir différentes instances...

Tu peux éviter cela en utilisant en cumulant les deux solutions, c'est à dire en utilsiant à la fois une interface et une enum :
Code:

1 2 3 public interface Calcul { public int calcul (String parametrePourCalcul); }
Qui sera implémenté par ton enum :

Code:

public enum ManieresDeCalcul implements Calcul {

L'intérêt, c'est qu'en utilisant l'interface Calcul au lieu de l'enum, ton code reste ouvert à des modifications "externes" sans que cela ne rentre obligatoirement dans l'enum. Ainsi, l'enum représente plutôt les manières de calcul standard ou par défaut, mais tu restes libre de proposer de nouvelles implémentations sans avoir forcément à modifier l'enum...

C'est une solution que je trouve très élégante, et qui a été adopté par le package java.nio.file de Java 7...

Après libre à toi de recherche le mode de calcul dans l'enum ou via une implémentation spécifique via la reflection, ce qui se révèle assez facile à implémenter :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 public static Calcul getCalcul(String name) { // On recherche d'abord l'enum via son nom : for (ManieresDeCalcul calcul : ManieresDeCalcul.values()) { if (name.equalsIgnoreCase(calcul.name())) { return calcul; } } // Sinon on considère qu'il s'agit d'un nom de classe : try { Class<?> clazz = Class.forName(name); // Et qu'elle implémente bien l'interface Calcul : if (Calcul.class.isAssignableFrom(clazz)) { return (Calcul) clazz.newInstance(); } } catch (Exception e) { // En cas d'erreur lors de la reflection : throw new IllegalArgumentException(name, e); } // On ne trouve rien de correspondant : throw new IllegalArgumentException(name); }
a++

Heo agiduba tu m'a piqué mon idée :mouarf: sauf que moi je n'utilise pas d'enum ce qui peut être utilisé avec n'importe quel version de java ;)
le tien->

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
try {
			Class<?> clazz = Class.forName(name);
			// Et qu'elle implémente bien l'interface Calcul :
			if (Calcul.class.isAssignableFrom(clazz)) {
				return (Calcul) clazz.newInstance();
			}
		} catch (Exception e) {
			// En cas d'erreur lors de la reflection :
			throw new IllegalArgumentException(name, e);
		}
		// On ne trouve rien de correspondant :
		throw new IllegalArgumentException(name);
	}

le mien où j'ai oublié d'instancier la classe :oops:

Code:

1
2
IManiere maniere = (IManiere) Class.forName(properties.get(maniere));
maniere.calcul(XXX);

A++

16/12/2009, 17h03
adiGuba

Citation:

Envoyé par hibour

Heo agiduba tu m'a piqué mon idée :mouarf: sauf que moi je n'utilise pas d'enum ce qui peut être utilisé avec n'importe quel version de java ;)

J'ai bien précisé que c'était une solution mixte entre les deux ;)

Citation:

Envoyé par adiGuba

en cumulant les deux solutions

L'intérêt (lorsqu'on peut les utiliser bien sûr), c'est que les enums facilitent certaines en évitant les duplications d'instances et en facilitant l'auto-complétion ;)

a++
16/12/2009, 17h25
hibour

Ok chef ;) pas de soucis. Les enum c'est bien quand les états sont fixe sinon c'est assez figé.
A++