なぜ配列はIListを実装するのですか？

System.Arrayクラスの定義を参照してください

public abstract class Array : IList, ...

理論的には、このビットを書いて幸せになれるはずです

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

また、iListから任意のメソッドを呼び出すことができるはずです。

 ilist.Add(1); //exception here

私の質問は、なぜ例外が発生するのかではなく、なぜArrayがIListを実装するのかです。

配列はインデックスによる高速アクセスを許可し、IList/ IList<T>はこれをサポートする唯一のコレクションインターフェイスであるためです。したがって、おそらくあなたの本当の質問は、「インデクサーを使用した定数コレクションのインターフェイスがないのはなぜですか？」そしてそれには答えがありません。

コレクションの読み取り専用インターフェースもありません。また、インデクサーインターフェイスを使用した一定のサイズ以上のものはありません。

IMOコレクションの機能に応じて、いくつかの（汎用）コレクションインターフェイスが必要です。Listインデクサー付きのものは本当に愚かなIMOであるため、名前も異なるはずです。

• ただの列挙 IEnumerable<T>
• 読み取り専用ですが、インデクサーはありません（.Count、.Contains、...）
• サイズ変更可能ですが、インデクサーはありません。つまり、（Add、Remove、...）currentのように設定されています ICollection<T>
• インデクサー付きの読み取り専用（インデクサー、indexof、...）
• インデクサー付きの一定サイズ（セッター付きのインデクサー）
• インデクサー付きの可変サイズ（挿入、...）現在 IList<T>

現在のコレクションインターフェイスはデザインが悪いと思います。しかし、それらには有効なメソッドを通知するプロパティがあるため（これはこれらのメソッドのコントラクトの一部です）、置換の原則に違反しません。

のためのドキュメントの備考セクションはIList言う

IListはICollectionインターフェイスの子孫であり、すべての非ジェネリックリストの基本インターフェイスです。 IList実装は、読み取り専用、固定サイズ、可変サイズの3つのカテゴリに分類されます。読み取り専用のIListは変更できません。固定サイズのIListでは要素の追加や削除はできませんが、既存の要素の変更は可能です。可変サイズのIListは、要素の追加、削除、および変更を可能にします。

明らかに配列は固定サイズのカテゴリーに分類されるため、インターフェースの定義により、それは理にかなっています。

すべてIListのが変更可能であるわけではなく（IList.IsFixedSizeおよびを参照IList.IsReadOnly）、配列は確かに固定サイズのリストのように動作します。

あなたの質問が本当に「非ジェネリックインターフェースを実装する理由」である場合、答えはジェネリックが登場する前にこれらがあったことです。

これは、読み取り専用のコレクションを処理する方法や、配列が読み取り専用であるかどうかが明確ではなかった時代から私たちが持っている遺産です。IListインターフェイスにはIsFixedSizeフラグとIsReadOnlyフラグがあります。IsReadOnlyフラグはコレクションをまったく変更できないことを意味し、IsFixedSizeはコレクションが変更を許可するがアイテムの追加または削除は許可しないことを意味します。

純4.5の時点で、そう、いくつかの「中間」のインターフェイスは、読み取り専用のコレクションで動作するように要求されていることが明らかになったIReadOnlyCollection<T>とIReadOnlyList<T>紹介されました。

ここでは詳細を説明する偉大なブログ記事です：.NETでの読み取り専用のコレクション

IListインターフェイスの定義は、「インデックスによって個別にアクセスできるオブジェクトの非ジェネリックコレクションを表します。」です。配列はこの定義を完全に満たすため、インターフェイスを実装する必要があります。Add（）メソッドの呼び出し時の例外は「System.NotSupportedException：コレクションは固定サイズでした」であり、配列が容量を動的に増やすことができないために発生しました その容量は、配列オブジェクトの作成時に定義されます。

IEnumerableをIList / ICollectionにキャストすると配列でも機能するため、配列にIList（および推移的にICollection）を実装すると、Linq2Objectsエンジンが簡素化されました。

たとえば、Count（）は、ICollectionにキャストされ、配列の実装がLengthを返すため、内部でArray.Lengthを呼び出すことになります。

これがなければ、Linq2Objectsエンジンは配列に対して特別な処理を行わず、恐ろしく実行するか、または（IListの場合と同様に）配列に対して特別なケースの処理を追加するコードを2倍にする必要があります。代わりに、配列にIListを実装させることを選択したに違いありません。

それが「なぜ」の私の見解です。

また、実装の詳細はLINQ LastがIListをチェックするため、リストを実装しなかった場合は、2つのチェックですべてのLast呼び出しが遅くなるか、配列のLastがO（N）を取得する必要があります。