C #: différence entre la liste < T > et Collection < T > (CA1002, Ne pas exposer les listes génériques) [dupliquer]

Question

    

Cette question a déjà une réponse ici:

    

        
•              Collection < T > versus List < T > Que devriez-vous utiliser sur vos interfaces?                                      8 réponses                          
    

    

Nous avons essayé d'exécuter l'analyse de code sur un projet ici et un certain nombre d'avertissements lui ont été adressés:

  

CA1002: Microsoft.Design: Modifier la liste < UnType > ' dans ' SomeClass.SomeProtectedOrPublicProperty ' pour utiliser Collection, ReadOnlyCollection ou KeyedCollection

Pourquoi devrais-je utiliser Collection < T > au lieu de Liste < T > ? Quand je regarde la documentation MSDN, ils semblent presque égaux. Après avoir lu l'aide d'erreur pour l'avertissement, j'ai constaté que

  

System.Collections.Generic.List (T) _est une collection générique conçue pour la performance, pas l'héritage, et ne contient donc aucun membre virtuel.

Mais qu'est-ce que cela signifie vraiment? Et que devrais-je faire à la place?

Dois-je continuer à utiliser Liste < T > en interne, puis dans les propriétés, renvoyer une nouvelle collection < T > (une liste) ? Ou devrais-je simplement commencer à utiliser Collection < T > au lieu de Liste < T > ?

Answer 1

En résumé, la liste générique n’a pas de méthodes virtuelles pour ajouter, supprimer, etc., car elle a été conçue pour être rapide et non extensible. Cela signifie que vous ne pouvez pas échanger cette implémentation concrète pour une sous-classe utile (même si vous pouvez la sous-classer car elle n'est pas scellée).

Par conséquent, en exposant la liste elle-même, vous ne pouvez jamais étendre votre collection pour suivre l'ajout ou la suppression d'opérations (par exemple) sans rompre le contrat public de la classe.

En exposant votre collection en tant qu'IList ou plus, vous pouvez toujours utiliser la liste en tant que magasin de sauvegarde, mais vous conservez l'extensibilité future car vous pouvez échanger ultérieurement l'implémentation concerete sans modifier le contrat public de votre classe. .

Answer 2

Collection expose certains membres virtuels (insertion, suppression, définition, suppression) que vous pouvez remplacer et fournir des fonctionnalités supplémentaires (telles que des événements de notification) lorsque la collection est modifiée.

Vous n'en avez peut-être pas besoin maintenant, mais il s'agit d'une exigence courante pour les classes contenant des collections. Il est donc préférable de le planifier à l'avance. Parce que Collection est conçu pour être extensible, il est très flexible. Si à l'avenir vous décidez que vous avez besoin d'une fonctionnalité supplémentaire dans la collection, vous pouvez simplement l'étendre sans aucune modification pour l'interface publique de la classe. Si vous aviez utilisé une liste, vous auriez dû la remplacer par une collection, ce qui aurait brisé tous les appelants de votre classe, car ils auraient dû être modifiés pour utiliser des listes.

List est quant à lui conçu avec les performances à l’esprit, il ne doit donc être utilisé que dans des cas spécifiques où les performances sont très importantes. Parce que ce n'est pas extensible, toute modification future apportée à quoi que ce soit en utilisant une liste casse tout le reste qui en dépend. Normalement, List ne devrait être utilisé en interne qu'au sein de classes de très bas niveau et ne doit être exposé à rien afin de réduire les risques de modifications ultérieures.