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

Question

Le code ressemble à ce qui suit :

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

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

Lorsque je lance l'analyse du code, j'obtiens la recommandation suivante.

Avertissement 3 CA1002 : Microsoft.Design : Remplacer 'List' dans 'IMyClass.GetList()' par Collection, ReadOnlyCollection ou KeyedCollection.

Comment puis-je résoudre ce problème et quelles sont les bonnes pratiques en la matière ?

Answer 1

Pour répondre à la partie "pourquoi" de la question de savoir pourquoi pas List<T> Les raisons en sont la pérennité et la simplicité de l'API.

Préparer l'avenir

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 qu'il contient ne sont pas virtuelles et ne peuvent donc pas être surchargées, et qu'il n'y a pas de crochets dans sa fonction Add / Insert / Remove opérations.

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 collection que vous retournez en un type que vous pouvez sous-classer, ce qui sera un changement d'interface de rupture (bien sûr, changer la sémantique des choses comme ne pas autoriser les objets nuls peut également être un changement d'interface, mais des choses comme la mise à jour de votre état de classe interne ne le serait pas).

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

Simplicité de l'API

List<T> contient un grand nombre d'opérations utiles telles que BinarySearch , Sort et ainsi de suite. 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, bien que votre classe puisse avoir besoin de ces opérations en interne, il est très peu probable que les consommateurs de votre classe veuillent (ou même doivent) les appeler.

Ainsi, en proposant une classe ou une interface de collection plus simple, vous réduisez le nombre de membres que les utilisateurs de votre API voient et vous facilitez son utilisation.

Answer 2

Personnellement, je déclarerais qu'elle renvoie une interface plutôt qu'une collection concrète. Si vous voulez vraiment un accès par liste, utilisez IList<T> . Sinon, on considère ICollection<T> y IEnumerable<T> .

Answer 3

Je ne pense pas que quelqu'un ait déjà répondu à la partie "pourquoi"... alors voilà. La raison pour laquelle vous "devriez" utiliser une Collection<T> au lieu d'un List<T> c'est parce que si vous exposez un List<T> alors toute personne ayant accès à votre objet peut modifier les éléments de la liste. Alors que Collection<T> est censé indiquer que vous créez vos propres méthodes "Ajouter", "Supprimer", etc.

Vous n'avez probablement pas besoin de vous en préoccuper, car vous codez probablement l'interface pour vous seul (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, comme il n'y a qu'un accesseur "get", personne ne peut modifier les valeurs, mais ce n'est pas le cas. Tout le monde peut modifier les valeurs à l'intérieur, comme ceci :

someObject.MyIngegers[3] = 12345;

Personnellement, j'utiliserais simplement 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 avez besoin de compter sur l'état des objets... alors vous voudrez faire votre propre Collection et la verrouiller à partir de là :)

Answer 4

Il s'agit surtout d'abstraire vos propres implémentations au lieu d'exposer l'objet Liste pour qu'il soit manipulé directement.

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

Collecte -> Pour une collecte 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(). Pouvez-vous nous en dire plus ?

Answer 5

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