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