Dlaczego tablica implementuje IList?

Zobacz definicję klasy System.Array

public abstract class Array : IList, ...

Teoretycznie powinienem być w stanie napisać ten fragment i być szczęśliwy

int[] list = new int[] {};
IList iList = (IList)list;

Powinienem również móc wywołać dowolną metodę z iList

 ilist.Add(1); //exception here

Moje pytanie nie brzmi: dlaczego otrzymuję wyjątek, ale raczej dlaczego Array implementuje IList ?

Ponieważ tablica umożliwia szybki dostęp przez indeks, a IList/ IList<T>to jedyne interfejsy kolekcji, które to obsługują. Więc może Twoje prawdziwe pytanie brzmi: „Dlaczego nie ma interfejsu dla stałych kolekcji z indeksatorami?” I na to nie mam odpowiedzi.

Nie ma też interfejsów tylko do odczytu dla kolekcji. I brakuje mi tych nawet bardziej niż stałego rozmiaru z interfejsem indeksatorów.

IMO powinno być kilka dodatkowych (ogólnych) interfejsów do zbierania danych, w zależności od cech zbioru. Nazwy też powinny być inne, Listbo coś z indeksatorem to naprawdę głupie IMO.

• Tylko wyliczenie IEnumerable<T>
• Tylko do odczytu, ale bez indeksatora (.Count, .Contains, ...)
• Możliwość zmiany rozmiaru, ale bez indeksatora, tj. Ustawiona jako (Dodaj, Usuń, ...) bieżąca ICollection<T>
• Tylko do odczytu z indeksatorem (indeksator, indeksowanie, ...)
• Stały rozmiar z indeksatorem (indeksator z ustawiaczem)
• Zmienny rozmiar z prądem indeksatora (Wstaw, ...) IList<T>

Myślę, że obecne interfejsy kolekcji są źle zaprojektowane. Ale ponieważ mają właściwości, które mówią ci, które metody są prawidłowe (i jest to część kontraktu tych metod), nie łamie zasady substytucji.

Uwag sekcję dokumentacji dla IListmówi

IList jest potomkiem interfejsu ICollection i jest interfejsem podstawowym wszystkich list nieogólnych. Implementacje IList dzielą się na trzy kategorie: tylko do odczytu, o stałym rozmiarze i o zmiennym rozmiarze . Nie można modyfikować IList tylko do odczytu. IList o stałym rozmiarze nie pozwala na dodawanie ani usuwanie elementów, ale umożliwia modyfikację istniejących elementów. IList o zmiennej wielkości umożliwia dodawanie, usuwanie i modyfikację elementów.

Oczywiście tablice należą do kategorii o stałym rozmiarze, więc ze względu na definicję interfejsu ma to sens.

Ponieważ nie wszystkie ILists są zmienne (zobacz IList.IsFixedSizei IList.IsReadOnly), a tablice z pewnością zachowują się jak listy o stałym rozmiarze.

Jeśli twoje pytanie naprawdę brzmi „dlaczego implementuje nieogólny interfejs”, to odpowiedź jest taka, że ​​były one w pobliżu, zanim pojawiły się generyczne.

To dziedzictwo, które mamy z czasów, gdy nie było jasne, jak radzić sobie z kolekcjami tylko do odczytu i czy Array jest tylko do odczytu. W interfejsie IList istnieją flagi IsFixedSize i IsReadOnly. Flaga IsReadOnly oznacza, że ​​nie można w ogóle zmienić kolekcji, a IsFixedSize oznacza, że ​​kolekcja umożliwia modyfikację, ale nie pozwala na dodawanie ani usuwanie elementów.

W czasie .Net 4.5 było jasne, że niektóre „pośrednie” interfejsy są wymagane do pracy przy zbiorach tylko do odczytu, więc IReadOnlyCollection<T>i IReadOnlyList<T>zostały wprowadzone.

Oto świetny wpis na blogu opisujący szczegóły: Kolekcje tylko do odczytu w .NET

Definicja interfejsu IList to „Reprezentuje nieogólną kolekcję obiektów, do których można uzyskać dostęp za pomocą indeksu”. Tablica całkowicie spełnia tę definicję, więc musi implementować interfejs. Wyjątkiem podczas wywoływania metody Add () jest „System.NotSupportedException: kolekcja miała stały rozmiar” i wystąpił, ponieważ tablica nie może dynamicznie zwiększać swojej pojemności. Jego pojemność jest określana podczas tworzenia obiektu tablicy.

Posiadanie tablicy implementującej IList (i przejściowo ICollection) uprościło aparat Linq2Objects, ponieważ rzutowanie IEnumerable na IList / ICollection działałoby również dla tablic.

Na przykład Count () kończy wywołanie Array.Length pod maską, ponieważ jest rzutowana na ICollection, a implementacja tablicy zwraca Length.

Bez tego silnik Linq2Objects nie byłby specjalnie traktowany dla tablic i działałby strasznie, albo musieliby podwoić kod, dodając specjalne traktowanie tablic (tak jak w przypadku IList). Musieli zamiast tego zdecydować się na implementację IList w tablicach.

To moje podejście do „Dlaczego”.

Również szczegóły implementacji LINQ Last sprawdza dla IList, jeśli nie zaimplementował listy, potrzebowałby albo 2 kontroli spowalniających wszystkie ostatnie wywołania, albo mieć Last on an Array biorąc O (N)