Discussion :

[dahtah]

Bonjour à tous,
J'ai besoin d'utiliser la réflexion dans le cadre d'un projet. Je connais peu ce sujet.
Je voudrais savoir s'il est possible de retrouver le type concret d'un objet abstrait.

Code :

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

1
2
3
 
//ObjetAbstrait étant une interface ou classe abstraite
ObjetAbstrait objet = new ObjetConcret();

A partir de objet est-il possible de retrouver le type ObjetConcret (pour caster par exemple)?
Tout les tutos que j'ai lu parle de retrouver des méthodes, classes... à partir de l'assembly ou de LateBinding, c'est très interessant mais inaproprié pour moi.
Merci.

[LoDev]

salut,
tu peux rajouter un private string nom = "nom de objet concret" (avec le nom de ton objet concret) dans les propriétés de ta classe et implémenté un getname().

[dahtah]

En fait j'ai trouvé, c'est tout simple.

Code :

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

if (objet is ObjetConcret) { ... }

Désolé du dérangement

[Guulh]

Code :

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

1
2
3
4
5
class Mere { }
class Fille : Mere { }
 
Mere i = new Fille();
Type t = i.GetType(); // renvoie Fille

[dahtah]

Code :

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

1
2
3
4
5
class Mere { }
class Fille : Mere { }
 
Mere i = new Fille();
Type t = i.GetType(); // renvoie Fille

interressant, je pensais que ça renverrai Mere...
Pour obtenir le type de Mere?

[Guulh]

Ca doit servir à rien.

Le compilo ne peut pas savoir que i est une Fille, c'est pour ça que la fonction (dynamique, hein, par essence ) existe. Selon les cas, i.GetType() renverra des choses différentes, pourvu que Mere soit héritable. Par contre, pour connaître le "type de référence" de i, suffit d'aller voir sa définition, ce qui peut être fait de façon statique.

Pour les membres d'une classe, un petit coup de réflexion doit permettre de récupérer le type de la référence qu'est i. Pour les variables définies dans les fonctions, eh beh je sais pas

[dahtah]

Code :

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

1
2
3
 
Mere objet = new Fille();
Object o = (Object)objet;

Est-ce que l'on peut retrouver le type Fille à partie de o? ça permettrait de faire des dictionnaires pour l'ensemble des objets :

Code :

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

1
2
3
4
Dictionary<int, Object> d = new Dictionary<int, Object>();
d.Add(1, objet);
Object test;
d.TryGetValue(int, out test);

On retrouve le type de base de test et on caste l'objet.
C'est possible?

[SirJulio]

L'object de type fille que tu as instancié, tu peux l'appeler et typer la variable comme tu veux, c'est et ca reste une fille (que tu la manipules par une reference Fille, Object, whatever).


Les dics d'objet, je ne vois pas trop l'interet. Si tu stockes des valeurs dans une collection, elles ont forcement un truc en commun que tu peux utiliser pour eviter le cast (c'est quand meme fait pour les generics), si elles n'ont rien en commun, il doit y avoir un probleme dans le design quelque part.

Travailler avec des collec d'objects qui peuvent potentiellement etre n'importe quoi, ca va etre super chiant, de recaster et travailler avec une valeur extraite (à grand coup de d'appel reflexif et de switch (Type) => tres moche).

Bref, les ....<Object>, c'est moche. =)

[Chubyone]

Bref, les ....<Object>, c'est moche. =)

C'est que les generics existent justement pour éviter les Collections d'Objets

[dahtah]

Je suis d'accord, je n'utilise jamais cettte méthode normallement.
J'ai trouvé un aure moyen plus propre d'arriver à ce que je veux, par une petite modififcation architecturale. Mais bon, je voulais apprendre un peu la réflexion et ses possibilités....
Tant pis, une autre fois.
Merci à tous.

[SirJulio]

Ouaip, je comprends bien, mais c'est justement ce à quoi la reflexion ne doit pas servir (combler quelque chose qui aurait pu etre resolu par une petite modification de design). La reflexion est extremement puissante, mais ca a un cout non negligeable (voire meme important suivant la manip en question, plus d'infos sur les differences invoke/call ici), c'est pour ca, AMHA, qu'il faut l'utiliser un dernier recours une fois que tu as epuisé tout le reste. Par exemple, la serailisation XML utilise massivement la reflexion pour "decouvrir" les champs d'une instance, ou encore tout le namespace Emit qui te permet de créer des types au runtime t'offrant des possiblités super interressante ("proxyiage" à l'execution etc).

Bref la reflexion, c'est vraiment un outil tres puissant, mais bien qu'il puisse servir pour tout, il y a assez peu de cas, ou on est reellement obligé de l'utiliser de maniere imperative, cet article explore un peu les usages de la reflexion sur .Net.

Bon courage.

[dahtah]

namespace Emit qui te permet de créer des types au runtime t'offrant des possiblités super interressante ("proxyiage" à l'execution etc).

Ouais j'ai lu un truc interressant la dessus. Il est possible de générer ses classes et de les compiler à la volée pendant l'éxecution. J'ai essayé ce matin, et c'est top (mais je pense que je m'en servirai jamais). C'est ce que je disais au début, tu trouves facilement des exemples très pointus, mais peu d'exemple applicatif, ou de réels utilisations de "tous les jours";
Enfin bref, la réflexion, c'est pour une autre fois.
Merci à tous.

[SirJulio]

Oui, c'est vraiment des aspects tres pointus en general qui necessite ce genre de bidouillage. Mais apres, ca peut resoudre des problematiques de tous les jours. Le meilleur exemple et le plus courant, le log d'appel. Bref, si tu veux voir ce qu'on peut faire avec Emit, tu as ce projet (LinFu) de Philip Laureano (pour le moment, il y a eu 4 parties à l'article) qui montre vraiment des possibilités tres interressantes d'Emit.

A noter juste qu'avec Emit, tu ne compiles pas justement, mais tu ecris directement de l'IL à la volée (contrairement à CodeDom), d'ou la modularité et les performances extremement interressantes. =)

Bonne lecture.