Discussion :

[Mose]

Je souhaite récupérer les interfaces implémentées par un Type donné.
Facile me direz vous : Type.GetInterfaces();

Oui mais non. GetInterfaces donne TOUTES les interfaces implémentées, or je ne veux que celles qui sont implémentées DIRECTEMENT.

Ex:

Code :

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

1
2
3
4
5
6
7
8
9
public interface I1
{
}
public interface I2 : I1
{
}
public class MaClass : I2
{
}

Ici, typeof(MaClass ).GetInterfaces me retourne les types I1 et I2, dans un ordre indéterminé.
Or j'ai besoin qu'il me retourne seulement I2, ou bien I2 en premier et I1 en deuxième.

J'ai la possibilité d'analyser ces interfaces pour voir si l'une est composée avec l'autre. Ca revient à recréer l'arborescence des interfaces, mais ça m'ennuie de faire ça, ça va me bouffer plein de ressources. Surtout dans un modèle ou on sur-exploite l'héritage d'implémentation (ça fait un algo d'analyse en 0(n²))

Merci...

[neguib]

...
Or j'ai besoin qu'il me retourne seulement I2, ou bien I2 en premier et I1 en deuxième...

Salut Mose
La question qui vient à l'esprit est : Pourquoi
Car quel est l'interêt de recréer tout de même une sorte de hiérarchisation puisque dans le principe il est normal que dans le cadre d'un héritage on puisse se contenter d'une indétermination de "qui implémente qui" au final
Maintenant, je ne connais pas la spécifité argumentée de ce besoin, donc eventuellement, il faudrait remonter à la classe de base puis redescendre pour déterminer par un comparatif des tableaux obtenus quoi est à qui(donc à mon avis pas très compliqué à remettre dans le "bon" ordre). Du point de vue des ressources, je ne crois pas t'avoir trouvé une solution par contre
A moins peut être qu'il soit possible (je n'ai pas testé) de jongler dans ton cas de figure avec Type.FindInterfaces

[Mose]

Merci de ta réponse.

Pourquoi ? Deux raisons.
1 - Pour dévier purement et simplement le fonctionnement de .Net et simuler l'héritage multiple

Je fait parti de ces puristes de l'objet qui s'insurgent contre l'absence de l'héritage multiple dans les derniers langages de haut niveau (Java et .Net). Pour compenser, je jongle avec les interfaces, mais j'ai besoin d'une hiérarchie dans les interface pour connaitre les "type" mères, et pas 'un des types hérités'.

2 - Dans le cadre d'un genre de "débuggeur", j'ai un TreeView dans lequel je peux mettre n'importe quel objet pour l'analyser. Pour des raisons de lisibilité, j'associe une icone par Type. Pour des raisons de simplicité, j'ai fait en sorte que si le type n'est pas associé à une icone (ni aucun de ses types de base), le TreeView va chercher si les interfaces de cet objet ont une icone associée. Jusqu'ici tout va bien.
Maintenant j'ai par exemple un objet de la classe Employé qui implémente IEmployé qui hérite de IPersonne.
Et à l'exécution, il me trouve IPersonne comme icone, alors que j'aurais voulu qu'il me sorte l'icone de IEmployé. Bref, la hiérarchie est passée à la trappe.

Bon... sur le fond j'en suis arrivé à la même solution que toi : je vais devoir créer ma propre hiérarchie des interfaces dans un coin histoire de déterminer l'ordre des héritages rapidement sans trop bourriner sur la Reflection.
C'est un petit peut plus compliqué que tu le dis, puisqu'il faut gérer l'héritage des interfaces des classes mères, et l'héritage des interfaces entre elles, sans oublier que l'héritage croisé d'interfaces peut faire des doublons. Mais bon.. c'est faisable.

[Nip]

As tu regarde du cote du design pattern composite? C'est normalement tout indique pour ton cas.

Je m'abstiendrai par ailleurs de tout commentaire sur la "purete" de l'heritage multiple ...mais c'est un sacre nid a m***e. (ah ben tiens si j'ai commente )

[Mose]

Mais si, c'est très bien l'héritage multiple. Faut juste beacoup de discipline, une seule façon de faire les choses (ou un IDE aui autogénère la plupart du code), et ça devient ultra puissant !!!

Merci pour la design pattern, je vais voir ce que je peux en tirer.