基本的に、クラスのユーザーができないという事実に混乱する可能性があるかどうかを判断する必要があります。たとえば、次のことができます。
for(int i=0; i=< myCollection.Count; i++)
{
... myCollection[i] ...
}
もちろん、foreach を使用することも、キャストを使用することもできます。
for(int i=0; i=< myCollection.Count; i++)
{
... ((Collection<MyType>)myCollection)[i] ...
}
ハイゼンバグに簡単につながる可能性があるため、簡単な決定ではありません。私は、クラスのユーザーからのアクセスがほとんど排他的にキーによって行われるアプリの 1 つで許可することにしました。
ただし、共有クラス ライブラリに対してそうするかどうかはわかりません。一般に、パブリック API で KeyedCollection を公開することは避けます。代わりに、パブリック API で IList<T> を公開し、API の消費者はキー付きアクセスが必要な場合は、IEnumerable<TItem> を受け取り、それをコレクションに取り込むコンストラクターを使用して、独自の内部 KeyedCollection を定義できます。これは、API から取得したリストから新しい KeyedCollection を簡単に構築できることを意味します。
シリアル化に関しては、Microsoft Connect に報告したパフォーマンスの問題もあります。KeyedCollection は内部辞書とリストを保持し、両方をシリアル化します。辞書は逆シリアル化で簡単に再作成できるため、リストをシリアル化するだけで十分です。
この理由と XmlSerialization のバグのため、KeyedCollection のシリアル化は避け、代わりに KeyedCollection.Items リストのみをシリアル化することをお勧めします。
int キーを別のタイプでラップするという提案は好きではありません。型を KeyedCollection のアイテムとして使用できるようにするために単純に複雑さを追加するのは間違っているように思えます。これを行うのではなく、文字列キー (ToString) を使用します。これは、VB6 Collection クラスに似ています。
FWIW、MSDN フォーラムで以前に同じ質問をしました。FxCop チームのメンバーからの回答がありますが、決定的なガイドラインはありません。