Kiedy używać IList, a kiedy List

Wiem, że IList to interfejs, a List to konkretny typ, ale nadal nie wiem, kiedy użyć każdego z nich. Teraz robię, jeśli nie potrzebuję metod Sort lub FindAll, których używam w interfejsie. Czy mam rację? Czy istnieje lepszy sposób decydowania, kiedy użyć interfejsu lub konkretnego typu?

Przestrzegam dwóch zasad:

• Zaakceptuj najbardziej podstawowy typ, który będzie działał
• Zwróć najbogatszy typ, jakiego będzie potrzebował twój użytkownik

Dlatego podczas pisania funkcji lub metody, która pobiera kolekcję, napisz ją, aby nie pobierała List, ale IList <T>, ICollection <T> lub IEnumerable <T>. Ogólne interfejsy będą nadal działać nawet w przypadku list heterogenicznych, ponieważ System.Object również może być literą T. Dzięki temu zaoszczędzisz sobie bólu głowy, jeśli zdecydujesz się użyć stosu lub innej struktury danych w dalszej części drogi. Jeśli wszystko, co musisz zrobić w funkcji, to zawsze przez nią, IEnumerable <T> jest naprawdę wszystkim, o co powinieneś prosić.

Z drugiej strony, zwracając obiekt z funkcji, chcesz dać użytkownikowi możliwie najbogatszy zestaw operacji bez konieczności wykonywania rzutów. W takim przypadku, jeśli jest to List <T> wewnętrznie, zwróć kopię jako List <T>.

Wytyczne firmy Microsoft sprawdzone przez FxCop odradzają używanie List <T> w publicznych interfejsach API - preferuj IList <T>.

Nawiasem mówiąc, teraz prawie zawsze deklaruję jednowymiarowe tablice jako IList <T>, co oznacza, że ​​mogę konsekwentnie używać właściwości IList <T> .Count zamiast Array.Length. Na przykład:

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;
    }
}

Jest ważna rzecz, którą ludzie zawsze przeoczają:

Możesz przekazać zwykłą tablicę do czegoś, co akceptuje IList<T>parametr, a następnie możesz wywołać IList.Add()i otrzymać wyjątek czasu wykonania:

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

Weźmy na przykład pod uwagę następujący kod:

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

Jeśli nazwiesz to w następujący sposób, otrzymasz wyjątek czasu wykonywania:

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

Dzieje się tak, ponieważ używanie zwykłych tablic z IList<T>narusza zasadę podstawienia Liskova.

Z tego powodu, jeśli dzwonisz, IList<T>.Add()możesz rozważyć wymaganie List<T>zamiast IList<T>.

Zgodziłbym się z radą Lee dotyczącą przyjmowania parametrów, ale nie zwracania.

Jeśli określisz metody, aby zwrócić interfejs, oznacza to, że możesz później zmienić dokładną implementację bez wiedzy zużywającej metody. Pomyślałem, że nigdy nie będę musiał zmieniać z List <T>, ale później musiałem zmienić, aby użyć niestandardowej biblioteki list dla dodatkowych funkcji, które zapewniała. Ponieważ zwróciłem tylko IList <T>, żadna z osób korzystających z biblioteki nie musiała zmieniać swojego kodu.

Oczywiście wystarczy to dotyczyć tylko metod, które są widoczne na zewnątrz (np. Metody publiczne). Osobiście używam interfejsów nawet w kodzie wewnętrznym, ale ponieważ możesz zmienić cały kod samodzielnie, jeśli wprowadzisz istotne zmiany, nie jest to absolutnie konieczne.

IEnumerable
Powinieneś spróbować użyć najmniej konkretnego typu, który odpowiada twojemu celowi.
IEnumerablejest mniej szczegółowy niż IList.
Używasz, IEnumerablegdy chcesz przeglądać elementy w kolekcji.

IList
IList implementuje IEnumerable.
Powinieneś używać, IListgdy potrzebujesz dostępu przez indeks do swojej kolekcji, dodawania i usuwania elementów itp.

Lista
List narzędzi IList.

Zawsze najlepiej jest używać najniższego możliwego typu podstawowego. Daje to osobie wdrażającej Twój interfejs lub konsumentowi Twojej metody możliwość wykorzystania za kulisami tego, co mu się podoba.

W przypadku kolekcji należy dążyć do używania IEnumerable tam, gdzie to możliwe. Daje to największą elastyczność, ale nie zawsze jest odpowiednie.

Jeśli pracujesz w ramach jednej metody (lub nawet w jednej klasie lub zestawie w niektórych przypadkach) i nikt z zewnątrz nie będzie widział, co robisz, użyj pełnej listy. Ale jeśli wchodzisz w interakcję z zewnętrznym kodem, na przykład gdy zwracasz listę z metody, chcesz tylko zadeklarować interfejs bez konieczności wiązania się z konkretną implementacją, zwłaszcza jeśli nie masz kontroli nad tym, kto kompiluje kod później. Jeśli zacząłeś od konkretnego typu i zdecydowałeś się zmienić na inny, nawet jeśli używa tego samego interfejsu, złamiesz kod kogoś innego, chyba że zacząłeś od interfejsu lub abstrakcyjnego typu bazowego.

Nie sądzę, żeby istniały sztywne i szybkie zasady dotyczące tego typu rzeczy, ale zwykle kieruję się zasadą używania najlżejszej możliwej drogi, dopóki nie będzie to absolutnie konieczne.

Na przykład, powiedzmy, że masz Personklasę i Groupklasę. GroupInstancja ma wielu ludzi, więc Lista tu miałoby sensu. Kiedy zadeklaruję obiekt listy w Group, IList<Person>użyję go i utworzę go jako plik List.

public class Group {
  private IList<Person> people;

  public Group() {
    this.people = new List<Person>();
  }
}

A jeśli nawet nie potrzebujesz wszystkiego IList, zawsze możesz użyć IEnumerable. W przypadku nowoczesnych kompilatorów i procesorów nie wydaje mi się, aby istniała żadna różnica w szybkości, więc jest to bardziej kwestia stylu.

Najczęściej lepiej jest używać najbardziej ogólnego użytecznego typu, w tym przypadku IList lub nawet lepiej interfejsu IEnumerable, dzięki czemu można wygodnie przełączać implementację w późniejszym czasie.

Jednak w .NET 2.0 jest irytująca rzecz - IList nie ma metody Sort () . Zamiast tego możesz użyć dostarczonego adaptera:

ArrayList.Adapter(list).Sort()

Powinieneś używać interfejsu tylko wtedy, gdy go potrzebujesz, np. Jeśli twoja lista jest rzutowana na implementację IList inną niż List. Dzieje się tak, na przykład, gdy używasz NHibernate, który rzutuje ILists do obiektu NHibernate bag podczas pobierania danych.

Jeśli List jest jedyną implementacją, której kiedykolwiek będziesz używać dla określonej kolekcji, możesz zadeklarować ją jako konkretną implementację List.

W sytuacjach, z którymi się zwykle spotykam, rzadko używam bezpośrednio IList.

Zwykle używam go jako argumentu do metody

void ProcessArrayData(IList almostAnyTypeOfArray)
{
    // Do some stuff with the IList array
}

Pozwoli mi to na przetwarzanie generyczne na prawie każdej tablicy w środowisku .NET, chyba że używa IEnumerable, a nie IList, co czasami się zdarza.

To naprawdę sprowadza się do rodzaju potrzebnej funkcjonalności. W większości przypadków sugerowałbym użycie klasy List. IList jest najlepszy, gdy trzeba utworzyć niestandardową tablicę, która mogłaby mieć bardzo specyficzne reguły, które chcesz zawrzeć w kolekcji, aby nie powtarzać się, ale nadal chcesz, aby .NET rozpoznał ją jako listę.

Obiekt AList pozwala na tworzenie listy, dodawanie rzeczy do niej, usuwanie, aktualizację, indeksowanie do niej itp. Lista jest używana zawsze, gdy chcesz mieć listę ogólną, w której określasz typ obiektu i to wszystko.

Z drugiej strony IList to interfejs. Zasadniczo, jeśli chcesz utworzyć własny typ listy, powiedzmy klasę listy o nazwie BookList, możesz użyć interfejsu, aby zapewnić podstawowe metody i strukturę nowej klasy. IList jest przeznaczony do tworzenia własnej, specjalnej podklasy, która implementuje List.

Inna różnica polega na tym, że IList jest interfejsem i nie można go utworzyć. Lista jest klasą i można ją utworzyć. To znaczy:

IList<string> MyList = new IList<string>();

List<string> MyList = new List<string>