Récupération de méthodes

Bonjour,
Le problème au quel je suis confronté est que: dans une classe JAVA on a des attributs et des méthodes,on a deux types de méthodes: les méthodes qui font que consulter et les méthodes qui peuvent transformer l'état de l'objet en manipulant un ou plusieurs des ses attributs.
Ce que je voudrai savoir c'est comment récupérer les méthodes qui transforment un de ces attribut.

ça fait un bon moment que j'essaye de régler ce problème mais sans succès.
Besoin d'aide S.V.P.

Cordialement Ylleria38

Bonjour,

Je sais pas si j'ai bien compris ta question, mais si tes méthodes (communément appelées getter et setter ) sont publiques, il te suffit d'avoir une instance d'un objet puis d'apeller ta methode comme suit :

Code:

---

instance.nomMethode()

---

salut.

Les Get et Set sont appelées les accesseurs qui permettent d'accéder et modifier les attributs protégées ou privées d'une classe.

Je crois que vous m'avez pas compris.
Or les accesseurs il y a d'autre méthodes qui peuvent changer les attribut aussi
par exemple si on a F1 qui est une file dans nos attributs et que dans une méthodes M1 on fais F1.add() on va changer l'attribut F1. moi ce que je voudrai
ces avoir la liste des méthodes qui peuvent changé l'attribut F1 par exemple.

Aucune chance... il faudrait analyser le bytecode de la méthode en question pour voir si (sous certaines conditions) elles peuvent faire muter l'objet.

Mais théoriquement, toutes les méthodes qui ne renvoient pas de résultat font muter un objet. Car une méthode qui ne fait pas muter l'objet ni ne renvoie de résultat ne fait rien!

Peut-être qu'en expliquant mieux le but, on pourrait trouver une solution, mais pour l'instant ta demande est juste impossible à réaliser...

;)

Citation:

---

Envoyé par ylleria38

ces avoir la liste des méthodes qui peuvent changé l'attribut F1 par exemple.

---

si tu es dans une même classe ,tu peux chercher les méthodes ayant comme paramètre l'attribut en question par exemple

De quel type est ton objet F1?

Il y a deux cas soit c'est toi qui a crée la classe, dans ce cas il n'existe que les méthodes que TU as crée.

soit c'est une classe de l'API, si tu travailles avec eclipse tu prends une instance avec un point

Code:

---

uneInstance.

---

et tu fais Ctrl + espace et tu auras la liste des méthodes.

mais que veut tu faire exactement?

Citation:

---

Envoyé par Pill_S

Aucune chance... il faudrait analyser le bytecode de la méthode en question pour voir si (sous certaines conditions) elles peuvent faire muter l'objet.

Mais théoriquement, toutes les méthodes qui ne renvoient pas de résultat font muter un objet. Car une méthode qui ne fait pas muter l'objet ni ne renvoie de résultat ne fait rien!

Peut-être qu'en expliquant mieux le but, on pourrait trouver une solution, mais pour l'instant ta demande est juste impossible à réaliser...

;)

---

Ok je vois mais tu pourrais m'expliquer un peut cette analyse du bytecode de la méthodes stp

ça s'appelle de la reflection . Elle te permet d'avoir la structure d'une classe avec la signature de ses méthodes mais le problème dans ton cas est que la signature n'est pas suffisante pour savoir si la méthode modifie un attribut ou pas sauf si tu vas éliminer des hypothèses.:ccool:

Citation:

---

Envoyé par jiddou

ça s'appelle de la reflection . Elle te permet d'avoir la structure d'une classe avec la signature de ses méthodes mais le problème dans ton cas est que la signature n'est pas suffisante pour savoir si la méthode modifie un attribut ou pas sauf si tu vas éliminer des hypothèses.:ccool:

---

Oui mais le reflection ne suffi pas pour régler mon problème

Non ça ne suffit pas, mais c'est deja un début.

Comme je l'ai dit, il faudrait analyser le code source / le byte code de la méthode (avec des outils "à la cglib") en question pour déterminer si il y a écriture de données. Cependant c'est une opération infiniment complexe et je crains que tu n'aie aucune chance d'y parvenir (c'est un travail titanesque qui n'est selon moi qu'à la portée des ingénieurs de chez sun, et même eux devraient réfléchir à 2 fois avant de se lancer dans une réalisation de ce type).

Tu n'as cependant toujours pas répondu à ma question: à quoi cela va-t-il servir? car j'ai beaucoup de mal à voire une réelle utilité à cela

Citation:

---

Envoyé par Pill_S

Non ça ne suffit pas, mais c'est deja un début.

Comme je l'ai dit, il faudrait analyser le code source / le byte code de la méthode (avec des outils "à la cglib") en question pour déterminer si il y a écriture de données. Cependant c'est une opération infiniment complexe et je crains que tu n'aie aucune chance d'y parvenir (c'est un travail titanesque qui n'est selon moi qu'à la portée des ingénieurs de chez sun, et même eux devraient réfléchir à 2 fois avant de se lancer dans une réalisation de ce type).

Tu n'as cependant toujours pas répondu à ma question: à quoi cela va-t-il servir? car j'ai beaucoup de mal à voire une réelle utilité à cela

---

Alors c'est pour ne tester que les méthodes susceptible de changé l'objet ;)

Bin c'est vraiment pas une bonne idée... il faut TOUT tester, y compris les méthodes qui renvoient simplement des résultats calculés à partir des valeurs de l'objet/des paramètres.

Prends cette simple méthode:

Code:

---

1 2 3 4

public static int somme(int i, int j) { return i * j; }

---

bien qu'elle ne fasse pas muter l'objet, il faut la tester, car l'implémentation que je viens d'écrire est foireuse ;)

Le debugueur eclipse affiche la valeur d'une variable en jaune quand cette variable change de valeur donc on peut le détecter au runtime.
Ton problème est complexe et ça mérite une très très ..... très longue réflexion :D
Sinon comme l'a bien dit Pill_S il faudrait analyser le bytecode et voir si on fait une affectation a un field ou appel d'une méthode qui change un field (utilisation de cglib, ASM...).
A++

Citation:

---

Envoyé par hibour

Le debugueur eclipse affiche la valeur d'une variable en jaune quand cette variable change de valeur donc on peut le détecter au runtime.

---

ouaip :)

mais eclipse ne sait pas "prédire" que telle variable sera modifiée ;)

Citation:

---

Pill_S
mais eclipse ne sait pas "prédire" que telle variable sera modifiée

---

Peut être eclipse le sait, à moins que t'avais dejà travaillé chez eclipse :lol:??!

Si t'as beaucoup de temps, je pense que une façon de faire serai d'utiliser JavaCC pour créer un parseur qui te permettera d'analyser le corps de tes méthodes et voir quels sont les attributs modifiés.
Tu pourras probablement trouver beaucoup de parseurs et grammaire existants pour Java mais tu dois les adapter pour ton besoin.
Ensuite tu pourras combiner l'utilisation de la réflexion et ton parseur pour trouver ce que tu veux.

Bon la parler c'est facile, je ne suis pas expert dans ce domaine mais je suis sure que ca se fais avec ca (peut être après que tu aies lu un livre sur les compilateurs :mouarf:).

Citation:

---

Envoyé par hibour

Peut être eclipse le sait, à moins que t'avais dejà travaillé chez eclipse :lol:??!

---

Eclipse sait probablement quelque chose de similaire, sinon il n'affichera pas un "warning" lorsqu'un attribut n'est jamais utilisé.

Il y a un monde entre savoir que quelque chose n'est pas utilisé, et savoir que quelque chose est utilisé.

Une petite idée. Tu pourras regarder si l'un des attributs de l'objet se trouve à gauche d'une expression ; Si oui alors la méthode modifie l'état de l'objet. Tout ça reste très théorique

Citation:

---

Envoyé par Nehmé

Si t'as beaucoup de temps, je pense que une façon de faire serai d'utiliser JavaCC pour créer un parseur qui te permettera d'analyser le corps de tes méthodes et voir quels sont les attributs modifiés.
Tu pourras probablement trouver beaucoup de parseurs et grammaire existants pour Java mais tu dois les adapter pour ton besoin.
Ensuite tu pourras combiner l'utilisation de la réflexion et ton parseur pour trouver ce que tu veux.

Bon la parler c'est facile, je ne suis pas expert dans ce domaine mais je suis sure que ca se fais avec ca (peut être après que tu aies lu un livre sur les compilateurs :mouarf:).

---

Je pense qu'on parlede trouver ca au runtime et dans ce cas on n'a pas les sources :mrgreen: -> ton javacc est inutilisable mais il faut analyser le bytecode.

bonjour,

après pour analyser le bytecode tu a des outil pas mal comme ASM.
mais bon tous ca reste quand même pas mal complexe ..

Alors quelqu'un a une solution :)?
thelvin: arrête de philosopher :mrgreen:

Citation:

---

Envoyé par hibour

Je pense qu'on parlede trouver ca au runtime et dans ce cas on n'a pas les sources :mrgreen: -> ton javacc est inutilisable mais il faut analyser le bytecode.

---

Si c'est pour faire un plugin Eclipse, le code source est accessible.
Il y a une API qui s'appelle JDT:
http://help.eclipse.org/galileo/inde...w-summary.html
très utile pour analyser le code java. (Merci à yann2 de me l'avoir montré)

Citation:

---

Envoyé par hibour

Alors quelqu'un a une solution :)?
thelvin: arrête de philosopher :mrgreen:

---

voila la solution:

Citation:

---

Envoyé par Pill_S

Aucune chance... il faudrait analyser le bytecode de la méthode en question pour voir si (sous certaines conditions) elles peuvent faire muter l'objet.

---

:p

De nombreux cas me semblent impossible à analyser, ne serait-ce qu'à cause de l'héritage.

Tu analyse une méthode toto qui appelle une méthode machin qui ne fait aucune modification.
Tu vas donc conclure que toto ne fait aucune modif non plus.

Manque de bol, dans une classe fille, la méthode machin est redéfinie et modifie l'état. Donc toto n'est plus "clean" dans cette classe fille.

A mon avis, tu pourras ne tirer de conclusions qu'avec des contraintes très strictes (pas d'appels à des méthodes non final ou non private).

oO je ne vois pas le problème il faut de toute manière analyser chaque méthode pour toute les classes (hériter ou pas) et tirer des conclusion pour chaque class a pars
ainsi la méthode toto sera clean dans la class mère est non-clean dans la class fille indépendamment l'une de l'autre.

Citation:

---

Envoyé par Pill_S

Aucune chance... il faudrait analyser le bytecode de la méthode en question pour voir si (sous certaines conditions) elles peuvent faire muter l'objet.

Mais théoriquement, toutes les méthodes qui ne renvoient pas de résultat font muter un objet. Car une méthode qui ne fait pas muter l'objet ni ne renvoie de résultat ne fait rien!

---

La question étant de savoir si on fait muter l'objet sur lequel s'applique la méthode, c'est plutôt faux, ça peut modifier l'état d'un autre objet, ou faire du log par exemple.

Citation:

---

Envoyé par Rei Ichido

La question étant de savoir si on fait muter l'objet sur lequel s'applique la méthode, c'est plutôt faux, ça peut modifier l'état d'un autre objet, ou faire du log par exemple.

---

faire muter l'object courant c'est faire muter une de ses propriétés... après, la mutation peut être directe (affectation d'un champ) ou indirecte, mais ça reste une mutation...

de toute façon c'est un faux débat, car le but étant de lister les méthodes qu'on doit tester car elles peuvent potentiellement changer l'état d'un objet, c'est pas vraiment exploitable dans le monde réel. Une méthode doit être testée si le code qu'elle contient est suffisament complexe pour risquer d'être incorrect (not "too simple to fail"). Enfin bon j'ai peut-être mal compris le but de ce post, mais perso je n'y vois aucun intérêt...

Je pense que la question posée est pertinente, son cas d'utilisation pour les tests est un peu absurde car le programmeur sait ce qui doit être testé ou non, mais on pourrai avoir besoin d'une tel opération pour savoir si une méthode est threadsafe par exemple (si on ne modifie aucune propriété par une méthode alors pas de risque de problème d'exclusion mutuelle) :)