De retour 'IList' vs 'ICollection' vs 'Collection'

Je suis confus au sujet de ce qui type de collection que je reviens de mon API publique des méthodes et des propriétés.

Les collections que j'ai à l'esprit sont IList, ICollection et Collection.

Est le retour de l'un de ces types toujours préféré aux autres, ou cela dépend-il de la situation spécifique?

InformationsquelleAutor Rocky Singh | 2012-03-24
  1. 66

    Généralement, vous devriez retourner un type qui est le plus général possible, c'est à dire celui qui sait juste assez de données retournées que le consommateur doit utiliser. De cette façon, vous avez plus de liberté pour changer la mise en œuvre de l'API, sans casser le code qui l'utilise.

    Prendre aussi en considération la IEnumerable<T> interface comme type de retour. Si le résultat est uniquement destiné à être itéré, le consommateur n'a pas besoin de plus.

    • Mais aussi envisager de ICollection<T> qui s'étend IEnumerable<T> de fournir des outils supplémentaires, y compris une propriété Count. Cela peut être utile parce que vous pouvez déterminer la longueur de la séquence sans traversant la séquence plusieurs fois.
    • Effectivement la mise en œuvre de la Count méthode vérifie le type réel de la collection, donc il va utiliser le Length ou Count propriétés pour certains types connus comme des tableaux et ICollection même lorsque vous les fournissez comme un IEnumerable.
    • génial merci pour l'info!
    • Il peut être intéressant de noter que si une classe Thing<T> implémente IList<T> mais non pas le non-générique ICollection, puis de l'appel d' IEnumerable<Cat>.Count() sur un Thing<Cat> serait rapide, mais en l'appelant IEnumerable<Animal>.Count() serait lente (depuis l'extension de la méthode de rechercher et de trouver une mise en œuvre de ICollection<Cat>). Si la classe n'implémente la non-générique ICollection, cependant, IEnumerable<Animal>.Count serait le trouver et l'utiliser.
    • MSDN lien vers Énumérable.Le comte
    • Je suis en désaccord. C'est mieux pour revenir le plus riche du type que vous avez, de sorte que le client peut l'utiliser directement si c'est ce qu'ils veulent. Si vous avez une Liste<>, pourquoi retourner un IEnuerable<> seulement à la force de l'appelant à l'appel ToList() inutilement ?
    • comment c# interface de mise en œuvre automatiquement???

    InformationsquelleAutor Guffa
  2. 128

    ICollection<T> est une interface qui expose la collection de la sémantique comme Add(), Remove(), et Count.

    Collection<T> est une mise en œuvre concrète de la ICollection<T> interface.

    IList<T> est essentiellement un ICollection<T> avec un ordre aléatoire-fonction d'accès.

    Dans ce cas, vous devez décider si oui ou non vos résultats nécessitent de la liste de la sémantique comme l'ordre en fonction de l'indexation (puis utilisez IList<T>) ou si vous avez juste besoin de retourner un non ordonnée "sac" de résultats (puis utilisez ICollection<T>).

    • +1 pour une bonne réponse. Cependant, je vous recommande l'ajout de quelques notes sur le principe général de l'abstraction, et pourquoi il favorise le retour de l'interface de types plutôt que le béton types de classe.
    • Collection<T> implémente IList<T> et pas seulement ICollection<T>.
    • Toutes les collections .Net sont commandés, parce que IEnumerable<T> est commandé. Ce qui distingue IList<T> de ICollection<T> est qu'il propose à ses membres de travailler avec les index. Par exemple list[5] fonctionne, mais collection[5] ne compile pas.
    • Je suis également en désaccord que les collections ordonnées doivent mettre en œuvre IList<T>. Il y a beaucoup de collections ordonnées qui ne le sont pas. IList<T> est sur rapide un accès indexé.
    • Il est intéressant de noter que, bien que IList<T> est un générique équivalent à IList, ICollection<T> et ICollection sont très différentes. Un générique Foo<T> qui implémente IList<T> souvent de ne pas mettre en œuvre non générique IList, mais doit encore mettre en œuvre les non-générique ICollection. Sinon, même si Foo<Cat> serait la mise en œuvre IEnumerable<Animal> et ICollection<Cat>, et le dernier exposer un rapide Count propriété, la IEnumerable<Animal>.Count() méthode d'extension ne serait pas en mesure d'utiliser le ICollection<Cat>.Count() mise en œuvre.
    • souligne que la Collection de<T> met en œuvre IList<T> -- cela me semble bizarre, quelqu'un sait pourquoi il a été fait de cette façon?
    • L' .collecte nette des classes et interfaces sont tout simplement mal conçu et mal nommée. Je ne pense pas trop pourquoi ils l'ont appelé comme ça.
    • désolé, la fin de la partie, mais la Collecte[je] ne compiler. Ai-je raté quelque chose?
    • Non, il n'est pas: ICollection<int> collection = new int[1]; Console.WriteLine(collection[0]);. Je suppose que vous avez essayé avec Collection<T>, pas ICollection<T>, mais ce n'est pas ce que je parlais.
    • Oui, vous avez raison. Je pensais que vous parliez de la Collection de<T>. Une autre question - Qu'entendez-vous par IEnumerable<T> est commandé? N'est-ce pas un détail d'implémentation? Par la manière, l'ordre peut être vrai pour une liste en mémoire, mais pas une liste de db.
    • Sont toutes les collections commandés en raison IEnumerable<T> est commandé? Prendre HashSet<T> - il implémente IEnumerable<T> mais n'est clairement pas commandé. I. e. vous n'avez aucune influence sur l'ordre des éléments et cet ordre peut changer à tout moment, si la table de hachage interne est organisé à nouveau.
    • Qu'entendez-vous par ordonné ? Je suis un peu confus par ce mot, voulez-vous dire qu'il est enchaîné comme une liste chaînée?
    • Je ne parle pas de la mise en œuvre, juste sur le fait que si vous parcourez une collection à l'aide foreach, vous obtenez les éléments dans un certain ordre, qui est définie par la collection.

    InformationsquelleAutor cordialgerm
  3. 55

    La principale différence entre IList<T> et ICollection<T> est que IList<T> vous permet d'accéder à des éléments via un index. IList<T> décrit semblable au tableau des types. Dans le cas d'une ICollection<T> ne peuvent être accessibles que par le biais de l'énumération. Les deux permettent l'insertion et la suppression d'éléments.

    Si vous avez seulement besoin d'énumérer une collection, puis IEnumerable<T> est à privilégier. Il a deux avantages sur les autres:

    1. Il n'autorise pas les modifications de la collection (mais pas pour les objets référencés, si elles sont de type de référence).

    2. Il permet la plus grande variété de sources, y compris les énumérations qui sont générées de manière algorithmique et ne sont pas des collections à tous.

    Collection<T> est une classe de base qui est principalement utile pour la mise en œuvre de collections. Si vous l'exposer dans les interfaces (Api), de nombreuses collections ne sont pas liés à elle sera exclue.

    Un inconvénient de IList<T> est que les piles de la mettre en œuvre, mais ne vous permet pas d'ajouter ou de supprimer des éléments (c'est à dire vous ne pouvez pas modifier la longueur du tableau). Une exception sera levée si vous appelez IList<T>.Add(item) sur un tableau. La situation est quelque peu désamorcée comme IList<T> a une propriété Booléenne IsReadOnly que vous pouvez vérifier avant de tenter de le faire. Mais à mes yeux, c'est encore un défaut de conception dans la bibliothèque. Donc, j'utilise List<T> directement, lorsque la possibilité d'ajouter ou de supprimer des éléments est nécessaire.

    • l'Analyse de Code (et FxCop) conseille que lors du retour d'un béton de collection générique, l'une des opérations suivantes doivent être retournés: Collection, ReadOnlyCollection ou KeyedCollection. Et que List ne doivent pas être retournés.
    • Souvent il est utile de passer d'une liste à une méthode qui a pour ajouter ou supprimer des éléments. Si vous tapez le paramètre comme IList<T>, il n'y a aucun moyen de s'assurer que la méthode ne sera pas appelé avec un tableau comme paramètre.
    InformationsquelleAutor Olivier Jacot-Descombes
  4. 6

    IList<T> est l'interface de base pour tous les génériques des listes. Puisque c'est une collection ordonnée, la mise en œuvre peut décider sur le bon de commande, allant de l'ordre de tri à l'ordre d'insertion. En outre Ilist a la propriété d'Élément qui permet à des méthodes pour lire et éditer des entrées dans la liste en fonction de leur index.
    Cela permet d'insérer, de supprimer une valeur dans la liste à un index de position.

    Aussi depuis IList<T> : ICollection<T>, toutes les méthodes de ICollection<T> sont également disponibles pour la mise en œuvre.

    ICollection<T> est l'interface de base pour tous les génériques des collections. Il définit la taille, les agents recenseurs et les méthodes de synchronisation. Vous pouvez ajouter ou supprimer un élément dans une collection, mais vous ne pouvez pas choisir à la position à laquelle il se produit en raison de l'absence de propriété index.

    Collection<T> fournit une implémentation IList<T>, IList et IReadOnlyList<T>.

    Si vous utilisez un étroit type d'interface tels que ICollection<T> au lieu de IList<T>, vous protégez votre code contre la rupture des changements. Si vous utilisez un large type d'interface tels que IList<T>, vous êtes plus en danger de rupture de modifications de code.

    Citant une source,

    ICollection, ICollection<T> : Vous souhaitez modifier la collecte ou l'
    vous vous souciez de sa taille.
    IList, IList<T>: Vous souhaitez modifier la collection et vous vous souciez de la commande et /ou de positionnement des éléments dans la collection.

    InformationsquelleAutor NullReference
  5. 4

    Retour d'un type d'interface est plus général, donc (à défaut de plus amples renseignements sur votre cas d'utilisation spécifiques), j'aurais pencher vers que. Si vous souhaitez exposer l'indexation de support, sélectionnez IList<T>, sinon ICollection<T> suffira. Enfin, si vous souhaitez indiquer que le retour de types sont en lecture seule, choisissez IEnumerable<T>.

    Et, dans le cas où vous ne l'avez pas lu avant, Brad Abrams et Krzysztof Cwalina a écrit un grand livre intitulé "le Cadre des lignes Directrices de Conception: les Conventions, les Idiomes et les Modèles Réutilisables .Bibliothèques NET" (vous pouvez télécharger un résumé de ici).

    • +1. Bonne lecture.
    • IEnumerable<T> est en lecture seule? Sûr, mais quand il faut relancer dans un contexte de référentiel, même après l'exécution de ToList n'est pas thread-safe. Problème, c'est quand la source de données d'origine devient GC, puis IEnumarble.ToList() ne fonctionne pas dans un contexte multithread. Il fonctionne sur un linéaire de un parce que GC est appelé après que vous faire le travail, mais à l'aide de async maintenant un jours à l'4.5+ IEnumarbale est en train de devenir un ballon mal.
    InformationsquelleAutor Alan
  6. -5

    Il y a des sujets qui viennent de cette question:

    • interfaces versus classes
    • qui classe spécifique, à partir de plusieurs comme les classes, de la collecte, de liste, de tableau ?
    • Commun des classes contre le point ("génériques") collections

    Vous souhaitez peut-être mettre en évidence que c'est un Orientée Objet A. P. I.

    interfaces versus classes

    Si vous n'avez pas beaucoup d'expérience avec les interfaces, je vous recommande de tenir aux classes.
    Je vois beaucoup de temps de développeurs de sauter à des interfaces, même si elle n'est pas necesarilly.

    Et à la fin faire une mauvaise conception de l'interface, au lieu de, une bonne conception de classe,
    qui, en passant, peut, éventuellement, être transféré dans une bonne conception de l'interface ...

    Vous verrez beaucoup d'interfaces dans A. P. I., mais, ne vous précipitez pas pour elle,
    si vous n'en avez pas besoin.

    Vous finirez par apprendre comment appliquer les interfaces, à votre code.

    qui classe spécifique, à partir de plusieurs comme les classes, de la collecte, de liste, de tableau ?

    Il y a plusieurs classes en c# (dotnet) qui peuvent être interchangés. Comme déjà dit, si vous avez besoin de quelque chose à partir d'une classe plus spécifique, telle que "CanBeSortedClass", puis de la rendre explicite dans votre A. P. I..

    Votre A. P. I. de l'utilisateur vraiment besoin de savoir que votre classe peut être triée, ou appliquer un format aux éléments ? Ensuite, utilisez le "CanBeSortedClass" ou "ElementsCanBePaintedClass",
    sinon, utiliser "GenericBrandClass".

    Sinon, utilisez une classe plus générale.

    Commun des classes de collection versus paragraphe ("génériques") collections

    Vous trouverez qu'il ya des classes qui contient d'autres éléments,
    et vous pouvez spécifier que tous les éléments doivent être d'un type spécifique.

    Générique Collections sont ceux des classes que vous pouvez utiliser la même collection,
    pour plusieurs applications de code, sans avoir à créer une nouvelle collection,
    pour chaque nouveau paragraphe, comme ceci: Collection.

    Votre A. P. I. utilisateur va avoir besoin d'un type très particulier, de même pour tous les éléments ?

    Utiliser quelque chose comme List<WashingtonApple> .

    Votre A. P. I. utilisateur va avoir besoin de plusieurs types ?

    Exposer List<Fruit> pour votre A. P. I., et l'utilisation List<Orange> List<Banana>, List<Strawberry> en interne, où Orange, Banana et Strawberry sont les descendants d' Fruit .

    Votre A. P. I. utilisateur va avoir besoin d'un type générique de la collection ?

    Utilisation List, où tous les éléments sont object (s).

    Acclamations.

    • "Si vous n'avez pas beaucoup d'expérience avec les interfaces, je vous recommande de tenir aux classes" Ce n'est pas un bon conseil. C'est comme dire que si il y a quelque chose que vous ne savez pas, il suffit de rester loin de lui. Les Interfaces sont extrêmement puissants et sauvegarder le concept de "Programme d'abstractions vs concrétions" Ils sont également assez puissant pour faire des tests unitaires en raison de la capacité d'échange types via des simulacres. Il y a un tas d'autres bonnes raisons d'utiliser les Interfaces au-delà de ces commentaires, s'il vous plaît par tous les moyens de les explorer.
    • J'ai régulièrement l'utilisation des interfaces, mais, comme beaucoup de concepts, de ses un outil puissant, il peut être facile à mélanger-utilisation. Et, parfois, le développeur n'a pas besoin. Ma suggestion n'était pas "ne jamais interfaces", ma proposition a été "dans ce cas, vous pouvez ignorer les interfaces. Apprendre à ce sujet, et vous pouvez obtenir le meilleur d'entre eux, plus tard". Des acclamations.
    • Je recommande toujours de programmation d'une interface. Il permet de garder le code faiblement couplés.
    • Ma réponse précédente (atconway) s'applique également à votre commentaire.
    InformationsquelleAutor umlcat