pour préciser, j'ai une méthode contrôles(nom) qui doit appeler une centaine de méthodes contrôles_nom(param...).
 
je pourrais coder un switch ... case nom1; contrôles_nom1(...) ... mais je souhaite 'dynamiser' cette gestion en associant au champ nom un champ méthode contrôles correspondant, dans un table oracle. Puis dire dans java : lit la table pour l'occurence nom et exécute la méthode contenu dans le champ ...
 
en cobol, on place dans le champ de la table le nom du programme à exécuter puis on fait un CALL champ_de_la_table.
 
y a t'il un équivalent ? ai-je posé le problème clairement ?
 
help    

mon dieu

oui, via l'objet method. mais c'est pas aussi simple qu'avec un eval()

En gros tu as tes methodes qui trainent dans une ou plusieurs classes. Si la classe n'est pas connue, tu l'obtiens pas Class.forName(). A partir de l'objet class, tu peux recuperer les methodes. Et enfin les appeler. Exemple pour une methode sans parametre :
 

 
et voila !

faut pas leur apprendre à faire ça
 
mauvais design, changer design, comme dirait l'autre.

certes, mais l'appel dynamique peux toujours servir a quelqu'un d'autre qui passerait par la  

lorill a écrit a écrit : certes, mais l'appel dynamique peux toujours servir a quelqu'un d'autre qui passerait par la

 
c'est LOURD et c'est BAD

 
Je t'avouerais que je m'en suis jamais servi en java, le truc du dessus c'est deviné apres lecture rapide de la doc. Mais j'ai deja fait des eval() dans d'autres langages, si tu maitrises ce que tu appeles je ne vois pas le probleme

meeeeeeeerci.  

ben en l'occurence... avec les noms de méthodes stockés dans une db, on peut pas dire qu'il maitrise

--greg-- a écrit a écrit : ben en l'occurence... avec les noms de méthodes stockés dans une db, on peut pas dire qu'il maitrise

 
C'est sur que c'est pas malin ni efficace. Mais ca ne remet pas en cause l'interet de la possibilité de decider quoi appeler a l'execution.

--greg-- a écrit a écrit : ben en l'occurence... avec les noms de méthodes stockés dans une db, on peut pas dire qu'il maitrise

 
en quoi est-ce que ce n'est pas propre ? c'est une appli batch qui reçoit des centaines de types de fichiers différents. On utilise une BDD pour recenser les types de flux. Plutôt que de coder en dur un switch avec des centaines de case identifiant_fichier; appelle méthodeX, on préfère recenser les méthodes à appeler dans la BDD et appeler la méthode dynamiquement.
 
Cela présente un avantage majeur: lorsqu'on doit adapter l'appli pour recevoir un nouveau type de flux, il suffit de mettre à jour la table et créer la méthode; il n'y a pas besoin de modifier la méthode appelante.
 
ça peut paraitre louche, mais bon on fait du batch pur et dur  
 
edit : je précise aussi (pour les questions de temp de traitement) qu'on fait pour d'autres raisons accès à la table en question, alors ramener un champ de plus ...

ben deja si c'etait dans un fichier de config, et pas dans une bd...

 
note c'est des choses qui arrivent malgré nous aussi  

DarkLord a écrit a écrit :     note c'est des choses qui arrivent malgré nous aussi

pas dans une bd quand meme
et puis là c'est pas malgré lui apparement

 
qu'est ce que vous trouvez choquant à mettre ce genre d'infos en BDD ? le pb du fichier de config, c'est de le mettre à jour quand il y a des nouveaux types de fichiers.

paske mettre à jour la db c'est pas chiant?

--greg-- a écrit a écrit : paske mettre à jour la db c'est pas chiant?

 
on a des accesseurs faits pour ...

 
bien sûr qu'on décide quoi appeler au moment de l'exécution; on a un composant manager qui reçoit les fichiers; en fonction du type, il exécute différentes méthodes de contrôles en fonction du fichier et il faut bien lui stipuler les méthodes à exécuter en fonction du fichier qu'il est en train de traiter.

--greg-- a écrit a écrit : pas dans une bd quand meme et puis là c'est pas malgré lui apparement

 
bin  

Oui, sauf que la machine virtuelle sait déjà faire cette sélection dynamique toute seule, et de manière bien plus efficace !!!    Ca s'appelle la liaison dynamique (late binding en anglais).    
 
Pour ce faire, il suffit d'une interface, qui définit le prototype de la méthode à appeler, une classe implémentant cette interface pour chacun de tes "contrôles", et une méthode factory qui va créer un objet de la bonne classe en fonction du nom du contrôle (enfin plutôt qu'une string pour ton "identifiant de contrôle", préfère un entier, car le switch sera, de très loin, beaucoup plus rapide). Et ne me dis pas que ça fait beaucoup de classes, car avoir des classes en plus n'a aucun coût supplémentaire à l'exécution et en l'occurrence, ça améliore la lisibilité et la maintenance du code.
 
Alors bien sûr, l'invocation dynamique explicite, telle que décrite par lorill, est possible, mais elle est coûteuse et elle outrepasse tous les contrôles que pourrait faire le compilateur. Et elle n'est vraiment nécessaire que quand on a besoin de faire une liaison dynamique à la fois sur le type de l'objet receveur ("this", quoi) et sur le type d'un ou plusieurs des arguments de la méthode.

et que j'y pense, bonjour la conception objet    
si au lieu d'avoir 204803 méthodes, tu avais 204803 objets qui implementent la meme interface... ça serait UN PEU plus "propre".
 
edit: enfin c ce que biface vient de dire en fait

Pas assez rapide, petit scarabée...

BifaceMcLeOD a écrit a écrit : Oui, sauf que la machine virtuelle sait déjà faire cette sélection dynamique toute seule, et de manière bien plus efficace !!!    Ca s'appelle la liaison dynamique (late binding en anglais).       Pour ce faire, il suffit d'une interface, qui définit le prototype de la méthode à appeler, une classe implémentant cette interface pour chacun de tes "contrôles", et une méthode factory qui va créer un objet de la bonne classe en fonction du nom du contrôle (enfin plutôt qu'une string pour ton "identifiant de contrôle", préfère un entier, car le switch sera, de très loin, beaucoup plus rapide). Et ne me dis pas que ça fait beaucoup de classes, car avoir des classes en plus n'a aucun coût supplémentaire à l'exécution et en l'occurrence, ça améliore la lisibilité et la maintenance du code.   Alors bien sûr, l'invocation dynamique explicite, telle que décrite par lorill, est possible, mais elle est coûteuse et elle outrepasse tous les contrôles que pourrait faire le compilateur. Et elle n'est vraiment nécessaire que quand on a besoin de faire une liaison dynamique à la fois sur le type de l'objet receveur ("this", quoi) et sur le type d'un ou plusieurs des arguments de la méthode.

 
pas la peine de s'échauffer, non plus, il y a des contraintes que je n'ai pas détaillées parce que je mettrai 100 pages à expliquer l'appli. reste que je ne peux pas mettre de switch, justement. j'avais bien pensé initialement avoir une interface "contrôles" et des classes spécifiques; je ne sais plus pkoi la solution a été écartée.

Ben, au jeu de la devinette, je dirais que pas de switch parce que l'identifiant n'est pas un atomique (typiquement une String -- bien qu'on puisse faire quand même un switch sur le hashCode d'une String si jamais c'est vraiment nécessaire).
Et au hasard, pas d'interface "contrôles" parce que toutes les méthodes n'ont pas le même prototype ?  

BifaceMcLeOD a écrit a écrit : Ben, au jeu de la devinette, je dirais que pas de switch parce que l'identifiant n'est pas un atomique (typiquement une String -- bien qu'on puisse faire quand même un switch sur le hashCode d'une String si jamais c'est vraiment nécessaire). Et au hasard, pas d'interface "contrôles" parce que toutes les méthodes n'ont pas le même prototype ?

si elles ont pas le meme prototype tu peux courir pour faire de l'invocation dynamique

 
classe java.lang.reflect.Method
Méthode invoke.
 
mé gruik

C'est clair que dans ce cas, on est obligé de recourir à Method.invoke(). Et il faut placer la séquence de code que tu as donnée dans chaque "case" du switch pour adapter le nombre et/ou le type des paramètres à chaque cas dans l'appel à Class.getDeclaredMethod().

--greg-- a écrit a écrit : faut pas leur apprendre à faire ça   mauvais design, changer design, comme dirait l'autre.

 
Je n'ai pas lu sa question, mais :
 
Tout depend de l'usage que tu en fais, je ne vois pas ce qu'il y a de mal a utiliser la reflexion.

ben lis sa question alors

--greg-- a écrit a écrit : ben lis sa question alors

 
Au vu de sa question je ne vois toujours pas de BONNE raison pour ne pas utiliser la reflexivite...  
 
Penser avoir qqch de dynamique et lui proposer d'utiliser des classes me fait rire : et si un type inattendu (classe non existante) doit etre traite ? Et si sa BDD est mise a jour par un autre moyen de maniere continue, et si, et si, etc... Rien ne t'assure que pour deux types differents tu doive toujours appeller deux methodes differentes...
 
Il peut y avoir 100000 raisons VALABLES d'utiliser une BDD et la reflexivite.
 
Le moyen le plus propre si c'est le cas est bel et bien de faire ce qu'il dit et de catcher une eventuelle exception. C'est loin d'etre sale si c'est adapte a ses besoins (s'il y besoin d'une vraie dynamique et ne peut se permettre de refaire la classe a tout bout de champ).
 
Par contre la pire des saletes est d'utiliser un fichier de config pour ce genre de trucs... Alors ca oui c'est SALE...
 
Ah oui dire que c'est un mauvais design alors que tu ne te demande meme pas pourquoi il utilise une BDD et quelles sont les implications de ce choix est un peu gonfle AMHA. PEut etre que tu n'as pas tors, mais ce n'est certainement pas avec le peu d'elements qu'il a fourni que tu peux juger en connaissance de cause.
 
(et pas besoin de t'enerver tout rouge j'ai certainement eu une journee plus difficile que la tienne)
 
Bobaille
 
 

 
 
quand au reste,   <-- ça veut pas dire que je trouve que tu racontes n'importe quoi, juste que j'ai la flemme d'argumenter    
chuis juste sur et certain qu'il y a moyen de trouver un design plus propre et/ou élégant, et surtout au final plus efficace/facile à maintenir/facire evoluer.
 
 

 
   
 
Je m'explique : malade et fievreux, reveil a 3h30 du mat, 10h de train dans la journee, 9h de conferences et de social relations, passe la journee a ecouter des gars parler de XML, .NET, CORBA, UDDI... retour et a 1h30 encore devant la machine a envoyer des mails.
 
Bref j'etais naze et ton " " m'a enerve
 
J'ai quand meme adore certaines discussions que j'ai eues dont une avec un responsable de la technologie .NET .  
 
J'ai adore lorsque apres 10 minutes de Discussions sur UDDI et JXTA et qu'on le travaille sur ce sujet et sur RDF, il m'a sorti "vous savez j'ai QUAND MEME travaille chez Silicon Graphics avant et je suis AVANT TOUT un ingenieur Linux... Donc ca m'interesse personnellement. Seulement ce dont vous me parlez c'est la concurrence donc pouvoir l'utiliser non, on peut seulement eventuellement essayer de copier certaines idees les meilleures bien sur (et il eclate de rire)"
 

bon ok pour la dure journée tu as gagné
 
faut savoir que le n'est pas aggressif hein
 
et excellent le mec de .NET
 
 

--greg-- a écrit a écrit : [quote] quand au reste,   <-- ça veut pas dire que je trouve que tu racontes n'importe quoi, juste que j'ai la flemme d'argumenter

ben moi je trouve qu'il a raison phenixl ...  

dites, les gars, ça part en couilles là et c'est pas le but.

mais nan ca part pas en couille ! c'est un poto greg !
 
moi je suis pour l'invocation dynamique, à moins que tu sois à quelques millisecondes près ...

 
ouééé \o/ je commencais a me sentir seul