私はここのヘラジカに同意します：_List<T>_は制約のない膨らんだオブジェクトであり、その中に「手荷物」がたくさんあります。
幸い、解決策は単純です。代わりに_IList<T>_を公開します。
（AddRange()のようなものを除いて）_List<T>_のメソッドのほとんどすべてを備えた最小限のインターフェースを公開し、特定の_List<T>_タイプに制約しないため、 APIコンシューマーが_IList<T>_の独自のカスタムインプリメンターを使用するようにします。
さらに柔軟性を高めるために、必要に応じて、一部のコレクションを_IEnumerable<T>_に公開することを検討してください。
主な理由は2つあります。
- List <T>はかなり膨らんだ型であり、多くのメンバーは多くのシナリオでは関係ありません（パブリックオブジェクトモデルには「ビジー」です）。
- クラスは封印されていませんが、拡張するように特別に設計されていません（メンバーをオーバーライドすることはできません）
何千または何百万もの開発者が使用するAPIを作成している場合は、悪い習慣と見なされます。
.NETフレームワーク設計ガイドラインは、MicrosoftのパブリックAPIを対象としています。
多くの人が使用していないAPIがある場合は、警告を無視してください。
私はあなたがあなたの消費者にあなたのリターンに新しい要素を追加してほしくないと思います。 APIは明確で完全でなければならず、それが配列を返す場合、正確なデータ構造を返す必要があります。私はそれがTごとに関係があるとは思わないが、直接配列[]ではなくList <>を返す
1つの理由は、Listがシミュレーションできるものではないためです。あまり人気のないライブラリでも、この推奨事項により、ListオブジェクトをIListとして公開するために使用された反復を見てきました。それ以降のバージョンでは、データをリストに（おそらくデータベースに）まったく保存しないことにしました。これはIListだったので、クライアントの下の実装を変更し、それでも全員が作業を続けることは、重大な変更ではありませんでした。
その理由の1つは、ユーザーがリストを変更でき、リストの所有者がこれを知らないためです。場合によっては、リストにアイテムを追加またはリストからアイテムを削除した後で、何らかの処理を行う必要があります。今は必須ではありませんが、将来必須になる可能性があります。したがって、クラスの所有者にAddXXX/RemoveXXXメソッドを追加し、IEnumerableのリストを公開するか、（私の意見ではより良い）IListとして公開し、WindowsBaseからObservableCollectionを使用することをお勧めします。