Discussion :

[El Saigneur]

Bonjour

Pour obtenir la superclasse d'une classe, on peut faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

clazz.getSuperclass();

Par contre, je ne sais comment faire pour obtenir les sous-classes d'une classe.
Pourriez vous m'aider ?

Merci

[adiGuba]

Salut,

Par contre, je ne sais comment faire pour obtenir les sous-classes d'une classe.

Ce n'est pas possible ! Tu dois charger toutes les classes pour vérifier si c'est une classe fille ou non...

Pourquoi as-tu besoin de cela ?

a++

[El Saigneur]

Il me semblait bien que ce n'était pas possible. Je suis parti pour boucler sur les classes chargées par le ClassLoader et vérifier une par une si elles étendent ma classe. C'est lourd mais je fais ça dans un Singleton Spring et je cacherai le résultat. Dommage que l'API ne propose pas cela. N'y aurait-il pas un outils "ReflectionUtils" qui permettrait de la faire ? Le "ReflectionUtils" de Spring ne le permet pas en tout cas. Peut être dans les bibliothèques Jakarta ? Mais j'ai pas trouvé.

J'ai besoin de faire cela pour du eager loading avec Hibernate. En fait, comme il est normal de la faire, j'ai mappé toutes mes relations en "lazy" afin de ne pas les charger inutilement. Selon les UseCases et les données des objets du domaine dont mes collègues ont besoin dans les couches supérieures de l'appli, je crée des DAO avec des "fetch join" pour minimiser le lazy-loading.
Cependant, pour certains UseCases, les couches du dessus ont besoin de charger tout le graphe de relations à partir d'un objet en haut de l'arbre (Comme si j'avais mappé toutes les relations en lazy="false"). Plutôt que d'écrire une Criteria avec près d'une cinquantaine de relations "fetch join" en dur dans le code, je suis parti pour faire de la réflexion sur l'objet en haut de l'arbre. Mon but est de parcourir ses fields et ceux de ses classes filles (là est mon problème) afin de repérer les relations vers d'autres objet du domaine mappés. J'ai défini une interface commune à tous les objets du domaine et utilise des HashSet génériques pour mes collections. Je peux donc en parcourant les fields savoir si la collection rencontrée est une relation vers d'autres objets du domaine et ainsi ajouter un "fetch join" sur cette relation avec l'API Criteria d'Hibernate. Je tire aussi parti des requêtes polymorphiques de Hibernate me permettant de faire un join sur des relations concernant des sous-classes de la classe définie pour la criteria. De plus, cette façon de faire rend la requête auto-maintenue. En effet, si une relation s'ajoute ou est supprimée dans le graphe, aucune modification n'est à effectuer dans ma méthode.

Bon bref. Il me faut parcourir le graphe d'héritage en descendant...

Donc si vous voyez un moyen moins lourd et plus élégant que de scruter le ClassLoader, je suis preneur.

D'avance Merci

[gifffftane]

Je flaire ici un anti-pattern.

(j'ai mis la définition du wikipedia anglais, parce que celle du dico de developpez.com ne me plait pas beaucoup).

Bon courage ! On a tous connu ça !

[the-gtm]

SessionFactory.get(All)ClassMetaData() ?

de tout façon parcourir toutes les classes du ClassLoader c'est vraiment un mauvaise idée. Surtout dans un serveur d'application où les class loaders sont propriétaires.

En plus si tu n'as pas de bol certaines classes n'auront pas encore été chargées et donc absentes du class loader

[El Saigneur]

En fait, j'étais déjà parti sur la solution de the-gtm. Effectivement les objets de domaine pouvant faire l'objet d'une jointure sont forcément des objets dont la mapping Hibernate est chargé dans la SessionFactory.

La méthode getAllClassMetaData() permet de récupérer toutes les ClassMetaData correspondant aux objets de domaine mappés dans la SessionFactory. Les ClassMetaData donnent tout un tas d'info et, pour ce qui m'intéresse, le nom de la classe mappée.

Merci pour vos réponses. Par contre je ne vois pas en quoi parcourir un arbre d'héritage de haut en bas est plus mauvais que de la parcourir de bas en haut. Il doit bien y avoir des cas où c'est nécessaire de procéder de la sorte.
Eclairez ma lanterne sinon...

A +

[gifffftane]

C'est parce que, s'il existe une solution fiable pour aller de l'enfant vers le père, il n'en existe pas pour aller du père vers l'enfant.

N'est-ce pas mieux ainsi ?...

(pour les reproductions sexuées, il faudrait plutôt parler de la mère, d'ailleurs, parce que le père....)

Pour une réponse plus informatique, je pense que la relation extends n'est pas symétrique, car il n'y a rien qui fixe le nombre de fils. Il est parfaitement possible de lancer un même programme avec différents classpath, et même de créer des classes pendant l'exécution d'un programme.

L'implémentation actuelle du XSLT dans JAXP, par exemple, crée de nouvelles classes à chaque transformation, pendant l'exécution.