Discussion :

[cyrano_de_bergerac]

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!

[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)

[tomlev]

Pour clarifier un peu les choses, voilà déjà un diagramme des interfaces concernées :


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>...

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

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.

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

[Pol63]

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 ^^

[cyrano_de_bergerac]

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

Encore quelques questions:

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:

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!

[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

[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 ! ) 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 ?

[tomlev]

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

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>

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>

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...

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