Discussion :

[orelero]

Bonjour,
Dans une application serveur, j'aimerai refactorer la partie qui gère les différentes commandes des applications clientes. En fait dés que le message est reçu, j'ai une suite de tests if/else imbriqués qui testent quelle est la commande et choisissent ensuite la methode appropriée pour traiter le message. Vu que j'ai pas mal de commandes différentes, je me dit qu'il faudrait un système plus rapide.
Pour cela je voulais créer une table de hashage==> clé:commande/valeur:nom de la methode qui convient.
Donc pour ça j'ai besoin de savoir comment invoquer une méthode par son nom.
Aussi, pensez-vous que que c'est une bonne solution ?
Merci !

[rozwel]

Effectivement tu as possibilité de faire quelque chose en utilisant la réflexivité. Jette un oeil à l'API de la classe java.lang.Class et notamment aux méthodes getMethod (si tu connais d'avance les paramètres). Sinon tu peux aussi parcourir le tableau retourné par getMethods() pour retrouver la méthode qui a le même nom. Une fois que tu as un objet Method, tu peux appeler invoke() dessus pour l'appeler.

[herve91]

Pour cela je voulais créer une table de hashage==> clé:commande/valeur:nom de la methode qui convient.
Donc pour ça j'ai besoin de savoir comment invoquer une méthode par son nom.

Sinon, tu peux faire plus simple que la réflexivité, en passant par la définition d'une interface.

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
public interface Executor {
  void execute(Command command);
}
 
Executor executor1 = new Executor() {
  public void execute(Command command) {
    ...
  }
};
...
 
HashMap executors = new HashMap();
 
executors.put("command1", executor1);
executors.put("command2", executor2);
...
 
Command command = request.getCommand();
Executor executor = (Executor) executors.get(command.getName());
if (executor != null) {
  executor.execute(command);
}

[Hephaistos007]

A mon avis, cette dernière solution n'est pas plus simple que la réflexivité.
Ca se fait en 1 ligne via l'API de réflexion et surtout, avec votre solution, si on ajoute une nouvelle méthode à la classe, il faut l'ajouter en conséquence dans la HashTable. L'introspection offerte par la réflexion dispense de ce travail.

[bouye]

Comme toujours avec les patterns et derives, cela depend de l'usage et de l'evolution future du programme. D'un cote on a un acces direct a la methode que l'on veut executer mais c'est "ecrit en dur" et on peut risquer de choper des NoSuchMethodException, IllegalAccess et autres (nottament en cas de faute de frappe puisque cela ne peut etre verifie a la compilation), etc... de l'autre c'est plus long a mettre en place mais apres on peut tres facilement reconfigurer la cible qui doit executer la commande appellee et l'interface garantie toujours que la methode appellee existe (bien qu'il soit possible de mettre un executor null dans la map par erreur)...

50/50

[orelero]

merci beaucoup pour vos réponses. Je penche plutôt pour la réflexion.

[orelero]

Désolé, je déterre le sujet mais c'est en lisant ça que j'ai changé d'avis et passer par une inerface comme Hervé l'a conseillé :
http://forum.java.sun.com/thread.jsp...sageID=3847442
D'aprés eux l'appel d'une methode par réflexivité est assez longue comparé à un test conditionnel . Qu'est ce que vous en pensez ?
Merci

[thibaut]

Oui c'est plus couteux evidemment... et de plus conceptuellement c'est faux car tu considére le code source comme des données de ton programme.

Pour moi utiliser la réflexivité c'est dans 80% des cas un erreur de conception et on peut s'en passer aisement.

[orelero]

en plus c'est difficilement compatible avec une obfuscation .
Sinon la méthode de Hervé te semble toi aussi meilleur que les tests ? (niveau performance).

[Hephaistos007]

... et de plus conceptuellement c'est faux car tu considére le code source comme des données de ton programme. Pour moi utiliser la réflexivité c'est dans 80% des cas un erreur de conception et on peut s'en passer aisement.

La différence entre une méta-classe et une classe est son niveau d'abstraction immédiatement supérieure. C'est une conception logicielle sur 2 niveaux, très propre. Mais comme tu l'as dis, ce n'est que ton avis.

[Marnor]

+1
Faudra que l'on dise aux développeurs des Ide java proposant l'autocomplétion... que leur facon d'aller chercher les méthodes est un problème de conception... lol Je sais pas ce qu'ils répondront...

Et moi aussi ce n'est que mon avis... (chacun le sien)...

[thibaut]

+1
Faudra que l'on dise aux développeurs des Ide java proposant l'autocomplétion... que leur facon d'aller chercher les méthodes est un problème de conception... lol Je sais pas ce qu'ils répondront...

Et moi aussi ce n'est que mon avis... (chacun le sien)...

Voilà pourquoi je dis 80% des cas...

[nletteron]

Mouerf je suis sceptique. Pour en rajouter une couche, va dire aux concepteurs des EJB qu'ils savent rien faire . Bref vous voyez un peu large dans vos pourcentages. J'ai du mal à saisir en quoi utiliser l'introspection est une source d'erreur de conception. Au niveau du développement je le vois mais au niveau conception, j'aimerais bien comprendre.

Mais ce n'est que mon avis

[thibaut]

Ben le soucis c'est que si jamais tu fais du refactoring: tu changes le nom de ta classe tu la supprime ou tu changes le nom de la méthode, tu auras un erreur à l'execution et non à la compilation.

Aprés tu fais ta vie, mais se retrouver avec une NoSuchMethodException en production ça fait un peu tache...