List IList List<T> etc.

Version imprimable

21/02/2011, 17h27
cyrano_de_bergerac

List IList List<T> etc.

Bonjour,

Premièrément, j'aimerai savoir s'il existe un tuto qui référencie bien les différences entre List, IList, List<T>, Hashtable, Collection, Dictionnary, etc.
Et même un schéma des rapports entre les classes serait cool!

Aussi je m'embrouille pas mal à l'utilisation de ces différentes classes ou interface.

Je sais que tout ce qui est IClasse est une interface de classe.
Mais j'ai du mal à comprendre quand utiliser IList plutôt que List et vice versa, et autres classes et interfaces du même style.

Autre exemple:
Si j'ai le choix entre List et List<T>, je choisis toujours List<T> qui me semble plus cadré et donc plus perfectionné.

J'ai cherché sur MSDN, mais ça ne répond pas à mes questions.

Merci à l'âme généreuse! :)
21/02/2011, 19h55
Pol63

une interface décrit des membres (fonctions, propriétés etc...)
elle doit etre implémentée par une classe qui contiendra le code des membres

on ne peut pas instancier une interface

l'utilité de l'interface peut etre par exemple de faire une fonction qui demande un IList, car dans la fonction tu n'as besoin de manipuler que les membres de IList, et à l'appel tu peux alors passer un List, un List<Integer> ou autre
alors que si tu fais une fonction qui demande un List<Integer> tu ne pourras pas lui donner autre chose

List imlémente IList, List<T> hérite de List
pour voir toute la hiérarchie je te conseille de regarder dans reflector, on peut voir les types de bases et les héritiers/implémenteurs de chaque classe (ainsi que ienumerable et d'autres)
dans un list on peut tout mélanger, dans un list<T> on ne peut mettre que des T (héritiés ou implémenteurs compris)

après le list est une collection indexée sur integer, de 0 à x
un dictionary est une collection indexée sur ce que tu veux, par exemple un dictionary<Texbox, Label> te permettrait de retrouver par rapport à un textbox le label qui lui est lié (nb la clé est hashé et il y a de la dicotomie pour retrouver un élément)
il y a le sortedlist pour des collections triées, le queue sert à faire du fifo, le stack sert à faire du lifo (l'inverse du queue)
etc...
dans l'aide tu trouveras pour chaque classe son utilité et la description de son fonctionnement (par exemple queue.enqueue pour ajouter un élément, queue.dequeue pour dépiler un élément)
22/02/2011, 02h35
tomlev

1 pièce(s) jointe(s)

Pour clarifier un peu les choses, voilà déjà un diagramme des interfaces concernées :
http://www.developpez.net/forums/att...1&d=1298337452

IEnumerable (et sa version générique IEnumerable<T>) représente une séquence d'éléments. On ne peut pas modifier le contenu, seulement obtenir les éléments un par un

ICollection(<T>) représente une collection d'éléments (ce qui étend la notion de séquence). On peut ajouter ou enlever des éléments, ou vider la collection. L'ordre des éléments est indéterminé (et donc leur position aussi)

IList(<T>) représente une collection d'éléments auxquels on peut accéder par leur position (index). Par exemple : ArrayList, List<T>, Collection<T>, les tableaux...

IDictionary(<TKey, TValue>) représente un dictionnaire de données, c'est à dire une collection de paires clé/valeur. L'ordre des éléments n'est pas connu, on ne peut donc pas y accéder par index, mais on peut accéder à un élément à l'aide de la clé associée. Par exemple : Hashtable, Dictionary<TKey, TValue>...

Citation:

Envoyé par cyrano_de_bergerac

Je sais que tout ce qui est IClasse est une interface de classe.
Mais j'ai du mal à comprendre quand utiliser IList plutôt que List et vice versa, et autres classes et interfaces du même style.

D'une manière générale, on utilise une interface pour faire abstraction du type concret. Par exemple, si tu as une méthode qui prend en paramètre une List<string>, tu ne pourras pas lui passer une collection d'un autre type que List<string>. Alors que si tu définis le type du paramètre comme étant IList<string>, n'importe quel type qui implémente cette interface pourra être passé en paramètre (Collection<string>, string[]...). C'est donc beaucoup moins restrictif que de spécifier le type concret

Citation:

Envoyé par cyrano_de_bergerac

Si j'ai le choix entre List et List<T>, je choisis toujours List<T> qui me semble plus cadré et donc plus perfectionné.

List tout court n'existe pas, tu parles peut-être de ArrayList ?
Dans ce cas tu as raison d'utiliser la version générique, à condition que tous les éléments de la liste soient de même type :
- c'est plus performant avec les types valeurs (car il n'y a pas besoin de boxing)
- tu peux détecter certaines erreurs dès la compilation (par exemple si tu essaies d'ajouter un int à une liste de string)
- tu évites d'avoir à faire des casts puisque les éléments de la liste sont fortement typés
- ça rend le code plus clair car on sait tout de suite ce que contient la liste en regardant sa déclaration

En gros, quand tu as le choix, utilise toujours la version générique.

Citation:

Envoyé par Pol63

List imlémente IList, List<T> hérite de List

List tout court n'existe pas, et List<T> n'hérite que de Object ;)
22/02/2011, 08h30
Pol63

Citation:

Envoyé par tomlev

List tout court n'existe pas, et List<T> n'hérite que de Object ;)

ah oui j'arrive à écrire des conneries en étant devant reflector ^^
08/03/2011, 18h11
cyrano_de_bergerac

Merci beaucoup pour vos réponses! :D
J'ai adoré le schéma que je n'arrivais pas à trouver, et qui répond bien à ce que j'attends. :ccool:

Encore quelques questions:

Citation:

List<T> n'hérite que de Object

Je pensais que List<T> pouvait hériter aussi d'une Collection<T>...?
Plus largemnent, existe t'il malgré tout une relation d'héritage entre les différentes classes qui implémentent les interfaces en question (ArrayList, List<T>, Dictionary<T, Value>, Hashtable, etc.?

Existe t'il des classes qui implémentent directement les interface IEnumerable, ICollection (et leur version générique avec <T>)?
Car dans ce que tu dis:

Citation:

IList(<T>) représente une collection d'éléments auxquels on peut accéder par leur position (index). Par exemple : ArrayList, List<T>, Collection<T>, les tableaux...

Collection<T> semble implémenter directement List<T>, ce qui me surprend car je pensais que cette classe implémentait directement ICollection<T>

Si une IList est attendue, peut-on retourner une IList<T> ou une List<T>, ou une ArrayList?

Merci encore pour votre aide!
08/03/2011, 18h22
Pol63

List<T> hérite de object, il implémente IList<T> et IList

IList<T> hérite de Icollection<T> qui hérite de IEnumerable<T> qui hérite de IEnumerable
IList hérite de ICollection qui hérite de IEnumerable

ce qui veut dire par exemple que dans un IList on peut mettre un List<T>

on peut voir ca dans reflector ainsi que toutes les autres questions que tu te poses sur les héritages et implémentations
08/03/2011, 18h29
Guulh

Pour savoir qui hérite de qui, le plus simple c'est de regarder : soit dans la doc, soit dans Visual Studio, en appuyant sur la touche F12 pendant que le curseur est sur le type en question.
Tu verras alors que List<T> n'hérite de rien, mais implémente IList<T> (tout comme Collection<T>, d'ailleurs) La différence entre les deux étant que Collection<T> a plusieurs méthodes virtuelles, qui fait d'elle une bonne classe de base pour des collections customs, alors que List<T> est plutôt faite pour être utilisée telle quelle. Et propose des tas de méthodes bien pratiques (de recherche, tri, ...) qui ne sont pas exposées par IList<T> (et qui plus est sont un peu rendues obsolètes par Linq)

Si une IList est attendue, tu dois retourner une IList (si ! :aie:) IList<T> n'hérite pas de IList, donc t'as la réponse à ta dernière question.

Mais ces interfaces de collection non génériques sont un reliquat de .Net < 2. Sauf à utiliser une librairie qui l'impose, tu peux (dois !) t'en passer. Et si List<T> implémente IList, c'est surtout pour faciliter la migration depuis ArrayList : le prototype des méthodes correctement découplées développé à l'époque de .Net 1.1 utilise IList et non pas ArrayList, et fonctionne donc tout pareil en lui donnant une List<T>.

S'il n'y avait pas la contrainte de compatibilité ascendante, IList, ICollection, ArrayList et consort auraient dégagé fissa. Surtout vu le nombre de posts sur ce forum qui mentionnent ces objets, alors que bon ils sont obsolètes depuis 6 ans :)

C'est clair ? :aie:
08/03/2011, 18h36
tomlev

Citation:

Envoyé par cyrano_de_bergerac

Je pensais que List<T> pouvait hériter aussi d'une Collection<T>...?

Non, les classes List<T> et Collection<T> implémentent les mêmes interfaces, mais n'héritent pas l'une de l'autre. Elles ont à peu près les mêmes caractéristiques, mais Collection<T> est plus adaptée comme classe de base pour créer ses propres collections

Citation:

Envoyé par cyrano_de_bergerac

Plus largemnent, existe t'il malgré tout une relation d'héritage entre les différentes classes qui implémentent les interfaces en question (ArrayList, List<T>, Dictionary<T, Value>, Hashtable, etc.?

La plupart du temps, non, les classes de collections n'héritent pas les unes des autres... mais il y a bien sûr des exceptions. Par exemple, tu rencontreras souvent des classes qui héritent de Collection<T>

Citation:

Envoyé par cyrano_de_bergerac

Existe t'il des classes qui implémentent directement les interface IEnumerable, ICollection (et leur version générique avec <T>)?

Comment ça "directement" ? Tu veux, dire, qui implémentent ICollection mais pas IList ? Il y en a quelques unes, par exemple HashSet<T>, qui représente un ensemble d'éléments sans doublon. L'ordre des éléments n'est pas défini, tu ne peux pas accéder à un élément par son index, donc ça n'implémente pas IList<T> mais seulement ICollection<T>

Citation:

Envoyé par cyrano_de_bergerac

Collection<T> semble implémenter directement List<T>, ce qui me surprend car je pensais que cette classe implémentait directement ICollection<T>

Elle implémente IList<T>, pas List<T> ;)
C'est vrai que le nom est trompeur...

Citation:

Envoyé par cyrano_de_bergerac

Si une IList est attendue, peut-on retourner une IList<T> ou une List<T>, ou une ArrayList?

Oui, n'importe quelle classe qui implémente IList fera l'affaire
08/03/2011, 18h45
tomlev
Citation:

Envoyé par Guulh

IList<T> n'hérite pas de IList

Effectivement... et ICollection<T> n'hérite pas de ICollection. Par contre IEnumerable<T> hérite de IEnumerable !

C'est un peu troublant, mais c'est normal... Supposons que ICollection<T> hérite de ICollection. On pourrait donc faire ceci :
Code:

1 2 ICollection<Dog> dogs = new List<Dog>(); ICollection animals = dogs;
Puisque ICollection.Add prend un paramètre de type Object, on peut ajouter n'importe quoi à animals :

Code:

animals.Add(new Cat());

Le problème, c'est qu'en réalité animals est une collection de chiens, pas de chats... et on aurait donc une erreur à l'exécution !

C'est pour ça que ICollection<T> n'hérite pas de ICollection (idem pour IList)

Par contre, pour IEnumerable, le problème est un peu différent : on ne peut pas modifier une collection via cette interface, mais seulement énumérer son contenu. Le problème expliqué plus haut ne se pose donc pas : une séquence de T (IEnumerable<T> peut très bien être utilisé comme séquence d'objets (IEnumerable), puisque T hérite forcément (directement ou non) de Object.

Plus d'explications à ce sujet ici :
http://blogs.msdn.com/b/brada/archiv...18/355755.aspx
08/03/2011, 18h59
cyrano_de_bergerac

Merci beaucoup pour vos réponses, et la dernière avec les chiens et le chat, explique bien la problématique! :ccool:

En fait, je comprends, mais il faut me rappeler à chaque fois, j'ai du mal à automatiser la compréhension sur ce sujet, avoir les bons réflexes de quelle classe est la plus pertinente à utiliser.

Mais je pense qu'il faut laisser du temps au temps, et qu'en pratiquant, ça va aider.

Bref merci mille fois pour tout! :D