Généricité dans les paramètres

Version imprimable

14/12/2010, 15h27
ToTo13

Généricité dans les paramètres

Bonjour,

pour la petite histoire, j'ai besoin de créer une sorte d'interface "Computable", qui me permettrait de savoir si une classe peut effectuer certains calculs.
Donc j'aurai une méthode "Compute(BufferedImage)" pour exécuter mes calculs.

Mais je souhaiterai aussi avoir une méthode "setParameters(...)" pour pouvoir affecter les paramètres de calculs aux classes.
Sauf que bien entendu, les paramètres sont évidemment différents en nombre et en type, en fonction des classes.

Donc ma première question est comment faire ?

Je sais qu'il existe deux solutions :
- avoir un argument de type String qui contient tous les noms des paramètres, leur valeur, le tout avec des séparateurs.
- une liste d'objets que l'on cast.
La première est lente mais souple d'utilisation, la deuxième est rapide mais impose d'avoir tous les arguments biens répartis.

Est ce que quelqu'un aurait une autre idée ?

Merci par avance...

La première solution qui me vient à l'esprit est de garder la deuxième option avec une liste de type acceptés (style des objets de type Comparable ou autre) :

Code:

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
	protected static List<Comparable<?>> acceptedTypes = null;
 
        static 
        {
		acceptedTypes = new ArrayList<Comparable<?>> ();
		acceptedTypes.add(new GregorianCalendar ());
		acceptedTypes.add(new Integer(0));
		acceptedTypes.add(new Double(0));
		acceptedTypes.add(new Float(0));
		acceptedTypes.add(new BigDecimal(0));
		acceptedTypes.add(new GenericOperand ());		
        }
	public static List<Comparable<?>> getAcceptedTypes() 
	{
		return acceptedTypes;
	}
 
	public static boolean isTypeAccepted(Class<?> type) 
	{
		Iterator<Comparable<?>> iter = acceptedTypes.iterator();
		while (iter.hasNext())
		{
			Comparable<?> typeinlist = iter.next();
			if (typeinlist.getClass() == type)
				return true;
		}
		return false;
	}

ou alors faire une List<ParametersAuth> ou chacun des type passés en paramètre doit étendre une inteface ParametersAuth avec dans les classes d'implémentation de cette interface un style de Wrapper.

14/12/2010, 15h39
ToTo13

Bonjour,

merci. Effectivement ce serait une version "propre" de ma deuxième proposition.
14/12/2010, 15h52
ToTo13

D'ailleurs, petite question annexe : comment faire si un des paramètres est un tableau à deux dimensions ?
14/12/2010, 16h30
Atatorus

Une autre solution encore plus souple serait d'utiliser une Map<String, Object> : la clé est le nom du paramètre, l'objet sera le paramètre. De cette manière, tu ne seras plus lié par l'ordre des paramètres, tu les récupères par le nom directement :

Code:

param = (Type) map.get("nom")

Il reste à connaître le type du paramètre selon son nom, mais je pense qu'une Map<String, Class> peut résoudre ce problème. Je ne sais pas si on peut faire un cast dynamique, sans connaître le type au moment de la compilation. Je pense que oui, mais je n'ai jamais pensé à tester ça.
14/12/2010, 16h34
ToTo13

Effectivement c'est une solution hybride sympathique.
Mais après réflexion, j'aime bien l'idée d'imposer le passage de tous les paramètres afin de minimiser les erreurs et l'éventuel casse tête du "qu'est ce que j'ai passé ou pas passé comme paramètre".
14/12/2010, 18h34
ep31

Citation:

Envoyé par ToTo13

D'ailleurs, petite question annexe : comment faire si un des paramètres est un tableau à deux dimensions ?

Il suffirait d'avoir un tableau d'objet acceptés du style :

Code:

protected static List<Class> acceptedTypes = null;

En y ajoutant les collections et mettre une clause de récursivité pour voir si les Objets contenus dans les Collections sont acceptés.

interfaces

Code:

1
2
3
interface Computable<T extends ComputeParameter>{
    public boolean compute(Image image, T parameters);
}

Code:

1
2
3
4
interface ComputeParameters{
    public int getParameterCount();
    public Object getParameter(int x);
}

implémentations:

Code:

1
2
3
4
5
6
7
class IntegerParameters implements ComputeParameters{
    @override    
    public int getParameterCount(){....}
    @override
    public Integer getParameter(int x){....}    
    public IntegerParameters(Integer[] parameters){....}
}

Code:

1
2
3
4
5
6
class IntegerBufferComputing implements Computable<IntegerParameters>{
 @override
 public boolean compute(Image image, IntegerParameters parameters){
    //....
 }
}

alternative, j'aime pas trop car les vararg et les generics, c'est pas vraiment recommandé...

Code:

1
2
3
interface Computable<T extends Object>{
    public boolean compute(Image image, T... parameters);
}

implémentations:

Code:

1
2
3
4
5
6
class IntegerBufferComputing implements Computable<IntegerParameters>{
 @override
 public boolean compute(Image image, Integer... parameters){
    //....
 }
}

15/12/2010, 09h38
Deaf

Bonjour!

Citation:

Envoyé par ToTo13

Sauf que bien entendu, les paramètres sont évidemment différents en nombre et en type, en fonction des classes.

Si tes paramètres changent en fonction de l'implémentation de Computable, cela signifie que celui qui paramètre doit connaîter l'implémentation utilisée pour paramétrer.

Donc pourquoi avoir un paramétrage générique?

Je vois deux possibilités:
- soit tu cast directement avec ton implémentation (puisque tu dois la connaître pour pouvoir paramétrer correctement),
- soit tu ajoutes un niveau d'interface supplémentaire entre Computable et ton implémentation pour regrouper les implémentations en fonction du paramétrage et tu cast avec cette interface.
15/12/2010, 11h08
ToTo13

Bonjour,

merci pour vos propositions, je vais faire des tests et me décider.
Finalement j'avais en tête les deux familles possibles et visiblement il n'en existe pas de troisième.

Salut,

Une autre solution basé sur l'exemple de tchize_ serait d'utiliser un objet pour paramétrer chaque "Computable", qui pourrait éventuellement être lié à une factory.

L'interface serait toute simple et se contenterait d'un argument Generics :
Code:

1 2 3 interface Computable<A>{ public boolean compute(Image image, A args); }
Ce qui sera déjà très pratique dans le cas où l'on utilise un seul paramètre :
Code:

1 2 3 4 5 6 7 class SimpleComputable implements Computable<Integer> { @Override public boolean compute(Image image, Integer value) { // *** return false; } }
Et dans les cas où l'on a besoin d'arguments plus nombreux, on passerait alors par une classe dédiée :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 class MyComputable implements Computable<MyArgs> { @Override public boolean compute(Image image, MyArgs args) { return compute(image, args.getValue(), args.getText(), args.getDate()); } private boolean compute(Image image, int value, String text, Date date) { // ... return false; } }
Avec la classe MyArgs représentant un simple beans :
Code:

1 2 3 4 5 6 7 8 class MyArgs { private int value; private String text; private Date date; // + getter/setter }
Exemple d'utilisation :
Code:

1 2 3 4 5 6 MyComputable c = ... MyArgs args = new MyArgs(); args.setValue(5); args.setText("Hello"); args.setDate(new Date()); c.compute(image, args);
Si on veut forcer l'utilisation de tous les attributs, on pourrait éventuellement utiliser un constructeur spécifique ou une simple factory :
Code:

1 2 3 4 5 6 7 public static MyArgs create(int value, String text, Date date) { MyArgs args = new MyArgs(); args.setValue(value); args.setText(text); args.setDate(date); return args; }
L'utilisation n'en serait que plus simple :
Code:

1 2 MyComputable c = ... c.compute(image, MyArgs.create(5, "Hello", new Date()));
a++

15/12/2010, 15h37
ToTo13

Bonjour,

merci pour cette nouvelle solution.
Petite précision : si je comprends correctement (rien n'est moins sûr), il y aura dans ce cas une classe d'argument par classe qui implémente Computable afin de pouvoir mettre ce que l'on souhaite dedans.
15/12/2010, 15h55
tchize_

heu non, regarde l'exemple, il y a une classe prenant un Integer, tout bete. Mais le problème reste entier, pour faire l'appel, tu devra savoir qu'on travaille avec un MyComputable et non pas avec un IntegerComputable. ;)
15/12/2010, 15h58
ToTo13

Euh... dsl mais il y a quelque chose que je ne saisi pas :aie:
Comment cela se passerait il si j'ai besoin de plusieurs int en paramètre.
Ce que je vois dans la classe MyArgs c'est des paramètre figés.
15/12/2010, 16h00
tchize_

soit tu fais un Computable<List<Integer>>
soit tu fais une class "arg" qui contient les ints dont tu as besoin et tu fais un Computable<MesAutresArgs>

personnellement j'utilise un truc un peu plus complexe:

Des paramètres avec un visiteur pour pouvoir les parcourir de manière générique

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
interface VisitorParameter{
 
	void visitParameter(ParameterInteger i);
	// and all other parameters
}
 
interface Parameter{
	void visit(VisitorParameter visitor);
}
 
class ParameterInteger implements Parameter{
	public int i;
 
	@Override
	public void visit(VisitorParameter visitor) {
		visitor.visitParameter(this);
	}
 
	public int get() {
		return i;
	}
}

des interfaces pour les traitements:

Code:

1
2
3
4
5
6
7
8
9
10
 
interface Arguments<T extends Parameter>{
	List<T> getAllArguments();
	void use();
}
 
interface Compute<E extends Arguments<?>>{
	void compute(E arguments);
	E createArgument();
}

une implémentation de traitement:

Code:

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
 
class ComputeExemple implements Compute<ComputeExempleArgument>{
 
	@Override
	public void compute(ComputeExempleArgument arguments) {
		arguments.i.get();
		// TODO Auto-generated method stub
	}
 
	@Override
	public ComputeExempleArgument createArgument(){
		return new ComputeExempleArgument();
	}
 
	class ComputeExempleArgument implements Arguments<ParameterInteger>{
 
		ParameterInteger i ;
 
		@Override
		public List<ParameterInteger> getAllArguments() {
			return Arrays.asList(i);
		}
 
		@Override
		public void use() {
			ComputeExemple.this.compute(this);
		}
 
	}
}

du coup, quand on possède une liste de traitements, on peut leurs demander de nous créer leurs paramètres, on peut les remplir et les utiliser pour exécuter le traitement.

exemple d'utilisation:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
public static void main(String[] args) {
	VisitorParameter visiteur = null;
 
	Compute<?> comp = null;
	//create args
	Arguments<?> arg = comp.createArgument();
	// do things on args like set
	for (Parameter parameter : arg.getAllArguments()){
		parameter.visit(visiteur);
	}
	// use it
	arg.use();
}

Le point problématique étant que le pattern visitor ne tolère pas/mal l'héritage, rendant l'ajout de nouveaux parameter moche si l'on ne peux pas modifier la définition du visitor.

15/12/2010, 16h39
ToTo13

Citation:

Envoyé par tchize_

soit tu fais un Computable<List<Integer>>
soit tu fais une class "arg" qui contient les ints dont tu as besoin et tu fais un Computable<MesAutresArgs>

Ok, c'est ce que je pensais. J'aimais pas les argument en dur sans une list.

Citation:

Envoyé par merill

personnellement j'utilise un truc un peu plus complexe...

Merci pour cette version.
Mais je ne vois pas vraiment l'intérêt de quelque chose aussi "complexe".
J'utilise List<Object> que je cast à ma guise, donc que mes classes peuvent reconstruire.
Si je souhaite avoir un nombre d'argument variable pour une même classe (ce n'est pas mon cas), je modifierai en faisant utilisant une Map<,> comme cela m'a été conseillé plus haut.

Citation:

Envoyé par ToTo13

Comment cela se passerait il si j'ai besoin de plusieurs int en paramètre.
Ce que je vois dans la classe MyArgs c'est des paramètre figés.

Oui chaque classe doit proposer sa propre "MyArgs" avec les paramètres qu'il lui faut...

Question subsidiaire : tu veux avoir quel niveau de vérification des paramètres ? A la compilation ou à l’exécution ?

Parce qu'en fait je me demande si une simple varargs ne serait pas suffisant :
Code:

1 2 3 4 public interface Computable { public boolean compute(Image image, Object... args) throws ClassCastException, ArrayIndexOutOfBoundsException; }
Que tu implémenterais tout simplement comme ceci :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 class MyComputable implements Computable { @Override public boolean compute(Image image, Object... args) { return compute(image, (Integer)args[0], (String)args[1], (Date)args[2]); } public boolean compute(Image image, int value, String text, Date date) { // ... return false; } }
Non ?

a++

15/12/2010, 18h08
merill

:P
C'est sûr que ton besoin, c'est un peu tuer un moustique avec un bazooka.

Avantage 1: Tu peux réussir à remplir tes paramètres de manière générique, sans avoir besoin de connaitre les implémentations des traitements.

Avantage 2: pas de cast.

A noter que si l'avantage 1, on s'en fout, on peut très bien virer l'histoire des Parameter et visitor. On se retrouve alors avec la première solution de adiGuba, qui a l'intérêt de ne pas avoir de cast à faire (je trouve cela plus safe).

C’est quoi un argument "en dur sans une liste"?
16/12/2010, 11h14
ToTo13

Citation:

Envoyé par adiGuba

Oui chaque classe doit proposer sa propre "MyArgs" avec les paramètres qu'il lui faut...

C'est ce qu'il me semblait avoir compris. :ccool:

Citation:

Envoyé par adiGuba

Question subsidiaire : tu veux avoir quel niveau de vérification des paramètres ? A la compilation ou à l’exécution ?

Parce qu'en fait je me demande si une simple varargs ne serait pas suffisant
Non ?

Oui :-)
Effectivement cela me suffit, car pour l'instant je passe par des listes d'arguments que je cast.

Du coup, petite question supplémentaire : quel est le problème avec les varargs qui ont été critiqué plus haut (du style, "moins on les utilise mieux c'est") ?
Est ce déconseillé ? Performance, compilation, lisibilité, etc. ?
16/12/2010, 13h20
adiGuba

C'est un soucis assez obscurs qui peut arriver lorsqu'on utilise des Generics couplé les varargs. Par exemple :

Code:

public static <T> void method(T...values)

Car si on utilise la méthode avec des types paramétrées, cela revient à faire un tableau de type Generics ce qui est bloqué par le langage (les tableaux vérifies les types à l'exécution, alors que les Generics les vérifient à la compilation).

Cela peut produire des cas d'erreur assez rare il faut l'avouer (mais cela provoque un warning si je ne me trompe pas).

Sinon il n'y a aucun problème particulier à utiliser les varargs...

a++
16/12/2010, 13h47
ToTo13

Merci pour l'info.
Comme je n'utilise pas de Générics... mon problème est réglé.
Je vais donc convertir toutes mes listes d'Object en varargs.