ContainerQueryゼロ個以上のContainerQueryClauseオブジェクトで構成される小さなユーティリティ クラスがあります。ユーザーがクエリを準備した後 (つまり、いくつかの句を追加した後)、私のフレームワークのインターフェイスは、以下をサポートするオブジェクトを取得する必要があります。
interface IContainerQuery
{
    public IEnumerable<ContainerQueryClause> Clauses { get; }
}
最適な実装とIContainerQueryその理由は何ですか?
オプション a)
class ContainerQuery
{
   public IEnumerable<ContainerQueryClause> Clauses { get; set; }
}
オプション b)
class ContainerQuery
{
    public ContainerQuery()
    {
        Clauses = new List<ContainerQueryClause>();
    }
    public ICollection<ContainerQueryClause> Clauses { get; private set; }
}
オプション c)
class ContainerQuery
{
    public ContainerQuery(IEnumerable<ContainerQueryClause> clauses)
    {
        Clauses = clauses;
    }
    public IEnumerable<ContainerQueryClause> Clauses { get; private set; }
}
オプション d)
上記のアプローチの組み合わせ、またはまったく異なるアプローチ。
サイドノート1:ContainerQuery現在は「列挙可能な節です」のように見えますが、 「列挙可能な節がある」ため、将来のためにモデル化したいと思います。
Q: type のプロパティを作成するための一般的なベスト プラクティス/パターンはありますIEnumerable<T>か? そうでない場合、どのアプローチがどの状況に適していますか?
副次的な質問:内部フレームワークが不変バージョンのみを使用するようにインターフェイスIContainerQueryを作成しますか?それとも、「内部コードは後でクエリを変更するほど愚かではない」ため、そうするのを控えますか?
追加のコンテキスト: ユーザーは新しいコンテナ クエリをインスタンス化し、いくつかの句を追加したいと考えています。ファンキーで流暢なインターフェイスなどはありません。完成したクエリをフレームワークに渡した後、フレームワークはすべての句を読み取るだけで、それを変更することはできません (インターフェイスの説明による)。