Retourner 'IList' vs 'ICollection' vs 'Collection'.

Question

Je ne sais pas quel type de collection je dois renvoyer à partir des méthodes et des propriétés de mon API publique.

Les collections auxquelles je pense sont IList , ICollection y Collection .

Le retour d'un de ces types est-il toujours préférable aux autres, ou cela dépend-il de la situation spécifique ?

Answer 1

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

Collection<T> est une implémentation concrète de la ICollection<T> interface.

IList<T> est essentiellement un ICollection<T> avec un accès aléatoire basé sur l'ordre.

Dans ce cas, vous devez décider si vos résultats nécessitent ou non une sémantique de liste telle que l'indexation basée sur l'ordre (utilisez alors IList<T> ) ou si vous avez simplement besoin de renvoyer un "sac" non ordonné de résultats (utilisez alors l'option ICollection<T> ).

Answer 2

En général, vous devez renvoyer un type aussi général que possible, c'est-à-dire un type qui connaît juste assez de données renvoyées pour que le consommateur puisse les utiliser. De cette façon, vous avez une plus grande liberté pour modifier l'implémentation de l'API, sans casser le code qui l'utilise.

Considérez également le IEnumerable<T> comme type de retour. Si le résultat ne doit être qu'itéré, le consommateur n'a pas besoin de plus que cela.

Answer 3

La principale différence entre les IList<T> y ICollection<T> interfaces est que IList<T> permet d'accéder aux éléments via un index. IList<T> décrit les types de type tableau. Les éléments d'un ICollection<T> ne sont accessibles que par énumération. Les deux permettent l'insertion et la suppression d'éléments.

Si vous avez seulement besoin d'énumérer une collection, alors IEnumerable<T> est à privilégier. Il présente deux avantages par rapport aux autres :

1. Il interdit les modifications de la collection (mais pas des éléments, s'ils sont de type référence).

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

3. Permet d'accéder à évaluation paresseuse et peuvent être interrogés avec LINQ.

Collection<T> est une classe de base qui est principalement utile aux implémenteurs de collections. Si vous l'exposez dans des interfaces (API), de nombreuses collections utiles qui ne dérivent pas d'elle seront exclues.

---

L'un des inconvénients de IList<T> est que les tableaux l'implémentent mais ne vous permettent pas d'ajouter ou de supprimer des éléments (c'est-à-dire que 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 car IList<T> a une propriété booléenne IsReadOnly que vous pouvez vérifier avant de tenter de le faire. Mais à mes yeux, il s'agit toujours d'un défaut de conception de la bibliothèque. . Par conséquent, j'utilise List<T> directement, lorsque la possibilité d'ajouter ou de supprimer des éléments est requise.

---

Lequel dois-je choisir ? Considérons seulement List<T> y IEnumerable<T> comme exemples de types spécialisés/généralisés :

• Méthode entrée paramètre
  • IEnumerable<T> La plus grande flexibilité pour l'appelant. Restrictif pour l'implémenteur, en lecture seule.
  • List<T> Restrictif pour l'appelant. Donne de la flexibilité à l'implémenteur, qui peut manipuler la collection.
• Méthode ouput ou valeur de retour
  • IEnumerable<T> Restrictif pour l'appelant, en lecture seule. La plus grande flexibilité pour l'implémenteur. Permet de retourner n'importe quelle collection ou d'implémenter un itérateur ( yield return ).
  • List<T> La plus grande flexibilité pour l'appelant, peut manipuler la collection retournée. Restrictif pour l'implémenteur.

Eh bien, à ce stade, vous pouvez être déçu parce que je ne vous donne pas une réponse simple. Une déclaration comme "toujours utiliser ceci pour l'entrée et cela pour la sortie" ne serait pas constructive. La réalité est que cela dépend du cas d'utilisation. Une méthode comme void AddMissingEntries(TColl collection) devra fournir un type de collection ayant un Add ou peut même exiger une HashSet<T> pour l'efficacité. Une méthode void PrintItems(TColl collection) peuvent vivre heureux avec un IEnumerable<T> .

Answer 4

Renvoyer un type d'interface est plus général, donc (sans plus d'informations sur votre cas d'utilisation spécifique) je pencherais pour cette option. Si vous voulez exposer le support de l'indexation, choisissez IList<T> sinon ICollection<T> suffira. Enfin, si vous voulez indiquer que les types retournés sont en lecture seule, choisissez IEnumerable<T> .

Et, au cas où vous ne l'auriez pas lu auparavant, Brad Abrams et Krzysztof Cwalina ont écrit un excellent livre intitulé "Framework Design Guidelines : Conventions, Idioms, and Patterns for Reusable .NET Libraries" (vous pouvez télécharger un résumé à partir de aquí ).

Answer 5

Il y a quelques sujets qui découlent de cette question :

• interfaces et classes
• quelle classe spécifique, parmi plusieurs classes similaires, collection, liste, tableau ?
• Classes communes et collections de sous-éléments ("génériques")

Vous pouvez souligner que c'est un Orienté objet A.P.I.

interfaces et classes

Si vous n'avez pas beaucoup d'expérience avec les interfaces, je vous recommande de vous en tenir aux classes. Je vois souvent des développeurs passer aux interfaces, même si ce n'est pas nécessaire.

Et, finir par faire un mauvais design d'interface, au lieu d'un bon design de classe, qui, d'ailleurs, peut éventuellement, être migré vers une bonne conception d'interface ...

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

Vous apprendrez éventuellement à appliquer les interfaces à votre code.

quelle classe spécifique, parmi plusieurs classes similaires, collection, liste, tableau ?

Il existe plusieurs classes en c# (dotnet) qui peuvent être interchangées. Comme déjà mentionné, si vous avez besoin de quelque chose d'une classe plus spécifique, comme "CanBeSortedClass", alors faites-le explicitement dans votre A.P.I..

Est-ce que votre utilisateur A.P.I. a vraiment besoin de savoir que votre classe peut être triée, ou appliquer un certain format aux éléments ? Alors utilisez "CanBeSortedClass" ou "ElementsCanBePaintedClass", sinon, utilisez "GenericBrandClass".

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

Classes de collections communes et collections de sous-éléments ("génériques")

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

Collections génériques sont ces classes que vous pouvez utiliser la même collection, pour plusieurs applications de code, sans avoir à créer une nouvelle collection, pour chaque nouveau type de sous-article, comme ceci : Collection .

L'utilisateur de votre A.P.I. va-t-il avoir besoin d'un type très spécifique, identique pour tous les éléments ?

Utilisez quelque chose comme List<WashingtonApple> .

Votre utilisateur d'A.P.I. va-t-il avoir besoin de plusieurs types d'accessoires ?

Exposez List<Fruit> pour ton A.P.I., et utilise List<Orange> List<Banana> , List<Strawberry> en interne, où Orange , Banana y Strawberry sont des descendants de Fruit .

Votre utilisateur A.P.I. va-t-il avoir besoin d'une collection de type générique ?

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

A la vôtre.