Class<T> t : comment executer et un méthode d'un type générique et avoir la valeur de retour ?

Bonjour à tous

j'ai cette classe :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

public class MaClasse <T, M> {   @Autowired private Class<T> membre1;   public Class<M> maMethodeQuiRenvoieUnResultat(Class<M> param1) { // Je veux pouvoir executer une methode qui est définie dans param1 (exemple cette méthode calcule et renvoie la date d'aujourd'hui+3 jours) // ça donnerait : Date d = param1.getDateDansTroisJours();   // ENSUITE :   // executer une méthode de membre1 qui prend une date en paramètre et renvoi un objet de type Class<M> // ça donnerait : Class<M> res = membre1.uneMethode(Date d); } }

---

Quelle est la meilleur façon de pouvoir accéder et executer donc les méthodes définies donc "Class<T> membre1" et "Class<M> param1" ?

En vous remerciant d'avance.

Salut,

Tu es obligé de mettre ton paramètre en class générique ? Tu ne peux pas utiliser une class mère ou encore une interface que tes classes implémenteraient ?

La méthode appelée dedans est toujours la même ? Ou elle change selon l'objet passé en paramètre ?

Merci pour ta réponse Badshade23,

Effectivement je pourrais mettre une classe mère ou interface (j'y pas pensé dans mon contexte actuel d'utilisation).
dans mon contexte le paramètre "param1" serait un un Service Springboot donc techniquement je peux faire hériter mes services depuis une classe service mere mais je ne sais si cela est cohérent étant donné que les services ne sont pas liés entre eux.

de la même manière pour le membre "membre1" qui serait un Repository.

quant à la méthode appelée, que ce soit pour le service ou le repository, elle ne change pas. mais j'aimerais aussi savoir comment faire dans le cas où elle changerait.

Merci

Citation:

---

Envoyé par lenas_tshaleb

Effectivement je pourrais mettre une classe mère ou interface (j'y pas pensé dans mon contexte actuel d'utilisation).
dans mon contexte le paramètre "param1" serait un un Service Springboot donc techniquement je peux faire hériter mes services depuis une classe service mere mais je ne sais si cela est cohérent étant donné que les services ne sont pas liés entre eux.

---

Personnelement, je n'ai jamais eu besoin de donner un service instancier par spring en paramètre a une méthode. Mais dans ton cas si vraiment tu veux faire une méthode générique au lieu de faire une class mère pour tes services je ferai plutôt une interface qui contient la ou les méthode que tes service doivent avoir en commun.

Citation:

---

Envoyé par lenas_tshaleb

mais j'aimerais aussi savoir comment faire dans le cas où elle changerai

---

Si après tu veux faire une méthode qui est générique et qui exécute une méthode choisi au dernier moment de ton objet générique passé en paramètre (pas sur que se soit français tout ça :roll: ).
Tu dois donner à ta méthode générique la méthode que celle*ci doit éxécuter (elle ne peut pas la deviner toute seule).

Citation:

---

Envoyé par lenas_tshaleb

de la même manière pour le membre "membre1" qui serait un Repository.

---

Code:

---

1 2	@Autowired private Class<T> membre1;

---

Je ne pense pas que tu puisses faire ça (à confirmer). Car tu demande à Spring de t'injecter un repository mais tu ne lui précise pas le quel ...
Il ne pourra pas le deviner tout seul encore une fois.

Citation:

---

Personnelement, je n'ai jamais eu besoin de donner un service instancier par spring en paramètre a une méthode. Mais dans ton cas si vraiment tu veux faire une méthode générique au lieu de faire une class mère pour tes services je ferai plutôt une interface qui contient la ou les méthode que tes service doivent avoir en commun.

---

Je rectifie : param1 serait une Entity SpringBoot et non pas un service (au temps pour moi).

Citation:

---

Tu dois donner à ta méthode générique la méthode que celle*ci doit éxécuter (elle ne peut pas la deviner toute seule).

---

Comment faire cela ? un exemple ?

Citation:

---

Je ne pense pas que tu puisses faire ça (à confirmer). Car tu demande à Spring de t'injecter un repository mais tu ne lui précise pas le quel ...
Il ne pourra pas le deviner tout seul encore une fois.

---

je doute aussi que cela marche car effectivement il essaye d'injecter quelque chose qu'il ne connait pas encore, je me demande si il y a une solution à ça en Java

Citation:

---

Envoyé par lenas_tshaleb

Comment faire cela ? un exemple ?

---

J'ai fait ça il y a longtemps il faudrait que je retrouve mon code ... Mais dans mes souvenirs je passais une instance d'un objet et un string (nom de la méthode) en paramètre de la méthode. Puis via une librairie tierce je faisais une sorte d’exécuter dessus. Actuellement je n'ai jamais eu besoin de réitérer ce style de code et niveau d’abstraction est pour moi rarissime et souvent peut-être effectuer autrement.

Citation:

---

Envoyé par lenas_tshaleb

je doute aussi que cela marche car effectivement il essaye d'injecter quelque chose qu'il ne connait pas encore, je me demande si il y a une solution à ça en Java

---

Pour moi c'est impossible. Quand tu lances ton conteneur Spring, il va scanner tous les répertoires que tu lui as indiqués (via @SpringBootApplication ou autre) et à chaque fois qu'il tombe sur une annotation, il regarde avant d'injecter l'objet si celui-ci existe déjà dans son contexte ou non. Si il ne le trouve pas, il l'instancie et le place dans son contexte (si c'est un singleton). Ici Spring ne peut pas l'instancier, il ne connaît pas la classe. Le niveau d'abstraction est beaucoup trop haut et pour moi ce n'est pas à Spring de gérer ça. Mais plutôt à toi, plus tard de set cet attribut. Apres peut être en utilisant le XML pour instancier le Bean et non l'annotation ... Mais encore une fois je ne pense pas que ce sois réalisable.

Tu ne peux pas traiter le problème autrement ? Pourquoi tu en es arriver à cette réflexion ?

J'ai trouvé comment faire :

Code:

---

1 2 3 4 5 6 7 8 9 10

try { Class<T> genericObj;   Method maMethode = genericObj.getClass().getDeclaredMethod("nomDeMaMethode", null); // null pour dire qu'elle n'a pas de paramètre String result = (String) maMethode.invoke(genericObj, new Object[0]); //new Object[0] pour ne pas mettre null car il attend une liste de params   } catch (NoSuchMethodException | SecurityException e) { e.printStackTrace(); }

---

pour le @autowired, j'ai directement passé le repo en paramètre en y declarant une interface dont hérite le repo.

Merci pour ton aide.

Hello,

oui bien entendu, la réflexion permet toujours de faire ça mais... C'est débile !

Tu as gagné quoi en faisant ça ? A quoi ça sert que le langage nous permette d'appeler directement les méthodes genre uneVariable.appelMethode(), si on préfère utiliser getDeclaredMethod()?

Ce que je veux dire c'est que si tu es content de ce que tu as maintenant, bon, dommage mais ça te regarde. Par contre personne qui assiste à ça ne doit croire que c'était une manière utile de faire quoi que ce soit.

ton commentaire est nul et complètement inutile !!

si tu ne peux pas donner un avis plus constructif, je t'invite à ne rien dire.

si tu ne peux pas comprendre l'utilité de certaines choses alors reste polie au moins !!

Absolument pas.

Je te l'ai dit, ce que tu fais, ça te regarde. Mais on ne peut pas abandonner un débutant qui tombe sur cette page et penserait que tout ça a un sens. Ça n'en a pas. C'est à ça que sert ce que je dis.

De toute façon quand je pose la question "à quoi ça sert", si ça sert vraiment à quelque chose eh bien il suffirait de répondre à la question. Quand au lieu de répondre on dit "si tu comprends pas à quoi ça sert c'est ton problème", c'est au mieux qu'on ne sait pas non plus à quoi ça sert. Au pire que personne ne le sait parce que ça ne sert à rien.

Voilà voilà voilà.

Citation:

---

Je te l'ai dit, ce que tu fais, ça te regarde. Mais on ne peut pas abandonner un débutant qui tombe sur cette page et penserait que tout ça a un sens. Ça n'en a pas. C'est à ça que sert ce que je dis.

---

La chose qui aurait été utile ici pour le débutant dont tu parle est que tu lui laisse un avis constructif qui l'aiderait, au lieu de critiquer et de laisser des avis nuls et sans aucune utilité !
Un débutant qui tombera sur cette page aura juste vu ton immaturité et ton ego .
J'ai posé la question sur MON sujet, et heureusement il y avait des gens plus sages et plus compétents qui ont su me répondre et m'orienter.
J'ai trouvé la solution qu'il me fallait dans MON contexte à moi, où tu n'as rien à y faire d'ailleurs, et je l'ai postée comme n'importe qui l'aurait fait, et en l'occurence ici la solution répond parfaitement au sujet de la discussion (et je ne te demande pas ton avis car je n'en ai pas besoin).

Citation:

---

De toute façon quand je pose la question "à quoi ça sert", si ça sert vraiment à quelque chose eh bien il suffirait de répondre à la question.

---

Mais tu te prends pour qui ? un dieu du code :ptdr: ? non, t'en es loin figure toi, très loin.
Vu ton immaturité et ta condescendence, je ne regrette pas de ne pas avoir répondu à la question comme tu l'aurais souhaité, ça n'aurait servi à RIEN.
De toute façon, pour moi, tu n'es personne, juste un pauvre type nul qui ne sait pas utiliser sa plume.

Citation:

---

Quand au lieu de répondre on dit "si tu comprends pas à quoi ça sert c'est ton problème", c'est au mieux qu'on ne sait pas non plus à quoi ça sert. Au pire que personne ne le sait parce que ça ne sert à rien.

---

Je te rassure, je sais parfaitement à quoi cela sert. Je me ferais un plaisir de l'expliquer à n'importe qui mais pas à toi, car de toute façon ton niveau est tellement bas que tu n'arriveras même pas à comprendre.


Voilà voilà voilà et encore voilà.

Bonjour,

je me permet d'amener mon petit grin de sel pour corriger un peu tout ce qui ne va pas et pourrait induire un débutant qui passe en erreur :) (Soyons constructif)

Tout d'abord ce code, le dernier fournit, ne peut pas être bon, impossible qu'il marche. :

Code:

---

1 2 3 4

Class<T> genericObj;   Method maMethode = genericObj.getClass().getDeclaredMethod("nomDeMaMethode", null); // null pour dire qu'elle n'a pas de paramètre String result = (String) maMethode.invoke(genericObj, new Object[0]); //new Object[0] pour ne pas mettre null car il attend une liste de params

---

genericObj est de type java.lang.Class, il n'a donc pas de méthode "nomDeMaMethode" et le seules méthodes qu'il peux avoir sont listée dans l'api java. En plus, Class est final, donc aucune sous classe ne peut exister. Je vais donc partir du principe que ce que l'on voulais écrire était en fait :

Code:

---

1 2 3

T genericObj; Method maMethode = genericObj.getClass().getDeclaredMethod("nomDeMaMethode", null); // null pour dire qu'elle n'a pas de paramètre String result = (String) maMethode.invoke(genericObj, new Object[0]); //new Object[0] pour ne pas mettre null car il attend une liste de params

---

Ce qui, même si ce n'est pas propre et dans les règle de l'art, a au moins le mérite d'avoir du sens (on recherche à invoquer "nomDeMaMethode" sur genericObj qui est de type T.
Corrigez moi si j'ai mal compris le problème de départ.
Du coup, le même problème est présent dans le bout de code de début

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

public class MaClasse <T, M> {   @Autowired private Class<T> membre1;   public Class<M> maMethodeQuiRenvoieUnResultat(Class<M> param1) { // Je veux pouvoir executer une methode qui est définie dans param1 (exemple cette méthode calcule et renvoie la date d'aujourd'hui+3 jours) // ça donnerait : Date d = param1.getDateDansTroisJours();   // ENSUITE :   // executer une méthode de membre1 qui prend une date en paramètre et renvoi un objet de type Class<M> // ça donnerait : Class<M> res = membre1.uneMethode(Date d); } }

---

où l'on devrait a priori lire ceci

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

public class MaClasse <T, M> {   @Autowired private T membre1;   public M maMethodeQuiRenvoieUnResultat(M param1) { // Je veux pouvoir executer une methode qui est définie dans param1 (exemple cette méthode calcule et renvoie la date d'aujourd'hui+3 jours) // ça donnerait : Date d = param1.getDateDansTroisJours();   // ENSUITE :   // executer une méthode de membre1 qui prend une date en paramètre et renvoi un objet de type Class<M> // ça donnerait :M res = membre1.uneMethode(Date d); } }

---

Que constate-t-on? (encore une fois corrigez si j'ai mal compris le contexte)
param1 doit disposer d'une méthode getDateDansTroisJours dont la signature est "Date getDateDansTroisJours()"
membre1 dispose d'une méthode "uneMethode" donc la signature est "M uneMethode(Date)"

mettons ça en musique. Comme j'ignore l'usage, je vais donner des noms un peu bateau à mes interfaces:

Code:

---

1 2 3 4 5 6 7

public interface Generateur { Date getDateDansTroisJours(); } public interface Transformateur<M> { public M uneMethode(Date date); }

---

ensuite, le code de la classe deviens

Code:

---

1 2 3 4 5 6 7 8 9 10

public class MaClasse<T extends Transformateur<M>, M extends Generateur > {   @Autowired private T membre1;   public M maMethodeQuiRenvoieUnResultat(M param1) { return membre1.uneMethode(param1.getDateDansTroisJours()); } }

---

et les différents paramètres / injection de notre MaClasse devront implémenter lesdites interfaces.

Ok, ça c'est la version simple. Notez le lien créé entre le Transformateur et M ;)

Maintenant je vais émettre 2 hypothèses alternatives possibles qui expliqueraient qu'on a cherché des solutions compliquées au problème.

La première c'est que le nom de la méthode est inconnu et fait l'objet d'un argument passé en paramètre de MaClasse qu'on ne voit pas dans l'exemple. Si le nom de la méthodes est inconnu, alors effectivement il faut passer par de la réflectivité je craint. Cependant, il faut sérieusement se poser la question de quel design a abouti à cela, car il devrait être extrêmement rare, sauf à designer des outils très générique (genre le coeur de spring), d'avoir besoin de sortir les apis reflectivité. Il vaut toujours mieux se baser sur les surcharges / redéfinitions et interfaces afin que le compilateur soit à même de faire son boulot de validation.

La seconde hypothèse alternative sur laquelle je vais m'étendre: on connait la méthode, on ignore son type de paramètre mais on sait qu'il est identique au type de paramètre retourné par getDateDansTroisJours dont on ignore aussi le type de retour. Il faut donc ajuster nos interfaces.

Code:

---

1 2 3 4 5 6

public interface Generateur<X> { X getDateDansTroisJours(); } public interface Transformateur<M, X> { public M uneMethode(X valeur); }

---

en on lie tout ça dans MaClasse

Code:

---

1 2 3 4 5 6 7 8 9 10

public class MaClasse<T extends Transformateur<M,X>, M extends Generateur<X>, X> {   @Autowired private T membre1;   public M maMethodeQuiRenvoieUnResultat(M param1) { return membre1.uneMethode(param1.getDateDansTroisJours()); } }

---

Citation:

---

Envoyé par lenas_tshaleb

dans mon contexte le paramètre "param1" serait un un Service Springboot donc techniquement je peux faire hériter mes services depuis une classe service mere mais je ne sais si cela est cohérent étant donné que les services ne sont pas liés entre eux.

---

C'est une question à débattre. Tu pourrais aussi mettre du code générique dans une interface et l'implémenter dans tous tes services. Vu qu'on ne voit pas concrètement ce que tu essaie de réaliser, c'est une peu compliqué de répondre de manière détaillée.

Edit: j'ai tappé le code de mémoire, je ne suis pas à l'abris d'un oubli ou d'une erreur ;)