2

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を作成しますか?それとも、「内部コードは後でクエリを変更するほど愚かではない」ため、そうするのを控えますか?


追加のコンテキスト: ユーザーは新しいコンテナ クエリをインスタンス化し、いくつかの句を追加したいと考えています。ファンキーで流暢なインターフェイスなどはありません。完成したクエリをフレームワークに渡した後、フレームワークはすべての句を読み取るだけで、それを変更することはできません (インターフェイスの説明による)。

4

1 に答える 1