Collection <T> versus List <T> que devez-vous utiliser sur vos interfaces?

Le code ressemble à ci-dessous:

namespace Test
{
    public interface IMyClass
    {
        List<IMyClass> GetList();
    }

    public class MyClass : IMyClass
    {
        public List<IMyClass> GetList()
        {
            return new List<IMyClass>();
        }
    }
}

Lorsque j'exécute l'analyse de code, j'obtiens la recommandation suivante.

Avertissement 3 CA1002: Microsoft.Design: Changez 'List' dans 'IMyClass.GetList ()' pour utiliser Collection, ReadOnlyCollection ou KeyedCollection

Comment résoudre ce problème et quelles sont les bonnes pratiques ici?

Pour répondre à la partie «pourquoi» de la question de savoir pourquoi pas List<T>, les raisons sont la pérennité et la simplicité de l'API.

À l'épreuve du futur

List<T>n'est pas conçu pour être facilement extensible en le sous-classant; il est conçu pour être rapide pour les implémentations internes. Vous remarquerez que les méthodes ne sont pas virtuelles et ne peuvent donc pas être remplacées, et qu'il n'y a pas de hooks dans ses opérations Add/ Insert/ Remove.

Cela signifie que si vous avez besoin de modifier le comportement de la collection à l'avenir (par exemple pour rejeter les objets nuls que les gens essaient d'ajouter, ou pour effectuer un travail supplémentaire lorsque cela se produit, comme la mise à jour de l'état de votre classe), vous devez changer le type de la collection que vous retournez à celle que vous pouvez sous-classer, ce qui sera un changement d'interface de rupture (bien sûr, changer la sémantique de choses comme ne pas autoriser null peut également être un changement d'interface, mais des choses comme la mise à jour de l'état de votre classe interne ne le seraient pas).

Ainsi, en renvoyant soit une classe qui peut être facilement sous-classée telle que Collection<T>ou une interface telle que IList<T>, ICollection<T>soit IEnumerable<T>vous pouvez modifier votre implémentation interne pour qu'elle soit un type de collection différent pour répondre à vos besoins, sans casser le code des consommateurs car il peut toujours être retourné comme le type qu'ils attendent.

Simplicité de l'API

List<T>contient de nombreuses opérations utiles telles que BinarySearch, Sortetc. Cependant, s'il s'agit d'une collection que vous exposez, il est probable que vous contrôliez la sémantique de la liste, et non les consommateurs. Ainsi, même si votre classe en interne peut avoir besoin de ces opérations, il est très peu probable que les consommateurs de votre classe veuillent (ou même devraient) les appeler.

En tant que tel, en offrant une classe ou une interface de collection plus simple, vous réduisez le nombre de membres que les utilisateurs de votre API voient et leur facilitez l'utilisation.

Je le déclarerais personnellement pour renvoyer une interface plutôt qu'une collection concrète. Si vous voulez vraiment accéder à la liste, utilisez IList<T>. Sinon, considérez ICollection<T>et IEnumerable<T>.

Je ne pense pas que quiconque ait encore répondu à la partie «pourquoi» ... alors voilà. La raison "pour laquelle" vous "devriez" utiliser a Collection<T>au lieu de a List<T>est que si vous exposez a List<T>, toute personne ayant accès à votre objet peut modifier les éléments de la liste. Attendu qu'il Collection<T>est censé indiquer que vous créez vos propres méthodes "Add", "Remove", etc.

Vous n'avez probablement pas à vous en soucier, car vous codez probablement l'interface pour vous-même uniquement (ou peut-être pour quelques collègues). Voici un autre exemple qui pourrait avoir du sens.

Si vous avez un tableau public, ex:

public int[] MyIntegers { get; }

On pourrait penser que parce qu'il n'y a qu'un accesseur "get", personne ne peut jouer avec les valeurs, mais ce n'est pas vrai. Tout le monde peut changer les valeurs à l'intérieur comme ceci:

someObject.MyIngegers[3] = 12345;

Personnellement, j'utiliserais juste List<T>dans la plupart des cas. Mais si vous concevez une bibliothèque de classes que vous allez donner à des développeurs aléatoires, et que vous devez vous fier à l'état des objets ... alors vous voudrez créer votre propre collection et la verrouiller à partir de là: )

Il s'agit principalement d'abstraire vos propres implémentations au lieu d'exposer l'objet List à manipuler directement.

Il n'est pas conseillé de laisser d'autres objets (ou personnes) modifier directement l'état de vos objets. Pensez aux getters / setters de propriété.

Collection -> Pour la collection normale
ReadOnlyCollection -> Pour les collections qui ne doivent pas être modifiées
KeyedCollection -> Lorsque vous voulez des dictionnaires à la place.

La façon de résoudre ce problème dépend de ce que vous voulez que votre classe fasse et de l'objectif de la méthode GetList (). Peux-tu élaborer?

Dans ce genre de cas, j'essaie généralement d'exposer le moins d'implémentation nécessaire. Si les consommateurs n'ont pas besoin de savoir que vous utilisez réellement une liste, vous n'avez pas besoin de renvoyer une liste. En retournant comme Microsoft suggère une collection, vous masquez le fait que vous utilisez une liste des consommateurs de votre classe et les isolez contre un changement interne.

Quelque chose à ajouter même si cela fait longtemps que cela n'a pas été demandé.

Lorsque votre type de liste dérive de List<T> au lieu de Collection<T>, vous ne pouvez pas implémenter les méthodes virtuelles protégées qui Collection<T>implémentent. Cela signifie que votre type dérivé ne peut pas répondre au cas où des modifications seraient apportées à la liste. Cela est dû au fait que List<T>vous en êtes conscient lorsque vous ajoutez ou supprimez des éléments. Être capable de répondre aux notifications est une surcharge et List<T>ne l'offre donc pas.

Dans les cas où un code externe a accès à votre collection, vous ne pouvez pas contrôler le moment où un élément est ajouté ou supprimé. Collection<T>Fournit donc un moyen de savoir quand votre liste a été modifiée.

Je ne vois aucun problème à renvoyer quelque chose comme

this.InternalData.Filter(crteria).ToList();

Si j'ai renvoyé une copie déconnectée de données internes ou un résultat détaché d'une requête de données, je peux retourner en toute sécuritéList<TItem> sans exposer aucun détail d'implémentation et permettre d'utiliser les données renvoyées de manière pratique.

Mais cela dépend du type de consommateur IEnumerable<TItem> auquel j'attends - si c'est quelque chose comme une grille de données, je préfère retourner, qui sera la liste des éléments copiée de toute façon dans la plupart des cas :)

Eh bien, la classe Collection n'est en réalité qu'une classe wrapper autour d'autres collections pour masquer leurs détails d'implémentation et d'autres fonctionnalités. Je pense que cela a quelque chose à voir avec la propriété masquant le modèle de codage dans les langages orientés objet.

Je pense que vous ne devriez pas vous en soucier, mais si vous voulez vraiment plaire à l'outil d'analyse de code, procédez comme suit:

//using System.Collections.ObjectModel;

Collection<MyClass> myCollection = new Collection<MyClass>(myList);