Quand utiliser IList et quand utiliser List ?

Question

Je sais que IList est l'interface et que List est le type concret, mais je ne sais toujours pas quand utiliser chacun d'eux. Ce que je fais maintenant, c'est que si je n'ai pas besoin des méthodes Sort ou FindAll, j'utilise l'interface. Ai-je raison ? Existe-t-il un meilleur moyen de décider quand utiliser l'interface ou le type concret ?

Answer 1

Il y a deux règles que je suis :

• Acceptez le type le plus basique qui fonctionnera
• Retournez le type le plus riche dont votre utilisateur aura besoin

Ainsi, lorsque vous écrivez une fonction ou une méthode qui prend une collection, écrivez-la non pas pour prendre une liste, mais une IList<T>, une ICollection<T> ou une IEnumerable<T>. Les interfaces génériques fonctionneront toujours, même pour les listes hétérogènes, car System.Object peut également être un T. Cela vous épargnera des maux de tête si vous décidez d'utiliser une pile ou une autre structure de données plus tard. Si tout ce que vous avez besoin de faire dans la fonction est de la parcourir par foreach, IEnumerable<T> est vraiment tout ce que vous devriez demander.

D'un autre côté, lorsqu'on renvoie un objet à partir d'une fonction, on veut donner à l'utilisateur l'ensemble le plus riche possible d'opérations sans qu'il ait à effectuer de castings. Dans ce cas, s'il s'agit d'une List<T> interne, renvoyez une copie en tant que List<T>.

Answer 2

Les directives de Microsoft, telles que vérifiées par FxCop, découragent l'utilisation de List<T> dans les API publiques - préférez IList<T>.

Par ailleurs, je déclare désormais presque toujours les tableaux unidimensionnels comme IList<T>, ce qui me permet d'utiliser systématiquement la propriété IList<T>.Count plutôt que Array.Length. Par exemple :

public interface IMyApi
{
    IList<int> GetReadOnlyValues();
}

public class MyApiImplementation : IMyApi
{
    public IList<int> GetReadOnlyValues()
    {
        List<int> myList = new List<int>();
        ... populate list
        return myList.AsReadOnly();
    }
}
public class MyMockApiImplementationForUnitTests : IMyApi
{
    public IList<int> GetReadOnlyValues()
    {
        IList<int> testValues = new int[] { 1, 2, 3 };
        return testValues;
    }
}

Answer 3

Il y a une chose importante que les gens semblent toujours négliger :

Vous pouvez passer un tableau simple à quelque chose qui accepte un tableau de type IList<T> et ensuite vous pouvez appeler IList.Add() et recevra une exception d'exécution :

Unhandled Exception: System.NotSupportedException: Collection was of a fixed size.

Par exemple, considérez le code suivant :

private void test(IList<int> list)
{
    list.Add(1);
}

Si vous l'appelez comme suit, vous obtiendrez une exception d'exécution :

int[] array = new int[0];
test(array);

Cela se produit parce que l'utilisation de tableaux simples avec IList<T> viole le principe de substitution de Liskov.

Pour cette raison, si vous appelez IList<T>.Add() vous pouvez envisager d'exiger un List<T> au lieu d'un IList<T> .

Answer 4

Je suis d'accord avec le conseil de Lee de prendre des paramètres, mais de ne pas revenir.

Si vous spécifiez que vos méthodes renvoient une interface, cela signifie que vous êtes libre de modifier ultérieurement l'implémentation exacte sans que la méthode consommatrice ne le sache jamais. Je pensais que je n'aurais jamais besoin de changer une liste<T>, mais j'ai dû changer plus tard pour utiliser une bibliothèque de listes personnalisée pour la fonctionnalité supplémentaire qu'elle fournissait. Comme je n'avais renvoyé qu'une IList<T>, aucune des personnes qui utilisaient la bibliothèque n'a dû modifier son code.

Bien sûr, cela ne doit s'appliquer qu'aux méthodes qui sont visibles de l'extérieur (c'est-à-dire les méthodes publiques). Personnellement, j'utilise les interfaces même dans le code interne, mais comme vous êtes en mesure de modifier tout le code vous-même si vous faites des changements cassants, ce n'est pas strictement nécessaire.

Answer 5

Il est toujours préférable d'utiliser le type de base le plus bas possible. Cela donne à l'implémenteur de votre interface, ou au consommateur de votre méthode, la possibilité d'utiliser ce qu'il veut dans les coulisses.

Pour les collections, vous devez utiliser IEnumerable dans la mesure du possible. Cette dernière offre le plus de flexibilité mais n'est pas toujours adaptée.