読み取り専用オブジェクトを返すベストプラクティス

C＃でのOOPに関する「ベストプラクティス」の質問があります（ただし、すべての言語に当てはまります）。

たとえば、プロパティアクセサを介して、パブリックに公開されるオブジェクトを含むライブラリクラスを持つことを検討してください。

class A
{
    // Note: List is just example, I am interested in objects in general.
    private List<string> _items = new List<string>() { "hello" }

    public List<string> Items
    {
        get
        {
            // Option A (not read-only), can be modified from outside:
            return _items;

            // Option B (sort-of read-only):
            return new List<string>( _items );

            // Option C, must change return type to ReadOnlyCollection<string>
            return new ReadOnlyCollection<string>( _items );
        }
    }
}

明らかに最適なアプローチは「オプションC」ですが、ReadOnlyバリアントを持つオブジェクトはごくわずかです（そして確かにユーザー定義クラスにはありません）。

あなたがクラスAのユーザーである場合、あなたは

List<string> someList = ( new A() ).Items;

元の（A）オブジェクトに伝搬しますか？または、コメント/ドキュメントに記述されているクローンを返すことはできますか？このクローンアプローチは、追跡が非常に難しいバグにつながる可能性があると思います。

C ++ではconstオブジェクトを返すことができ、constとしてマークされたメソッドしか呼び出せないことを覚えています。C＃にはそのような機能/パターンはないのでしょうか？そうでない場合、なぜ含まれないのですか？const constnessと呼ばれると思います。

しかし、再び私の主な質問は、「何を期待しますか」またはオプションAとBの処理方法についてです。

コレクションの最良の解決策である@Jesseの答えに加えて、一般的なアイデアは、Aのパブリックインターフェイスを、それだけが返されるように設計することです。

• 値型（int、double、structなど）

• 不変オブジェクト（ "string"など、またはクラスAと同様に読み取り専用メソッドのみを提供するユーザー定義クラス）

• （必要な場合のみ）：「オプションB」が示すように、オブジェクトのコピー

IEnumerable<immutable_type_here> それ自体は不変であるため、これは上記の特別な場合にすぎません。

また、インターフェイスにプログラミングする必要があることに注意してくださいIEnumerable<string>。概して、そのプロパティから返されるものはです。A List<string>は一般的に可変であるため、A は少しノーです。これはReadOnlyCollection<string>、実装者としてICollection<string>はLiskov Substitution Principleに違反しているように感じられると言っています。

しばらく前と同様の問題に遭遇しましたが、それは私の解決策でしたが、実際にはライブラリを制御する場合にのみ機能します：

クラスから始めましょう A

public class A
{
    private int _n;
    public int N
    {
        get { return _n; }
        set { _n = value; }
    }
}

次に、プロパティのget部分（および読み取りメソッド）のみを使用して、これからインターフェイスを派生させ、Aにそれを実装させます。

public interface IReadOnlyA
{
    public int N { get; }
}
public class A : IReadOnlyA
{
    private int _n;
    public int N
    {
        get { return _n; }
        set { _n = value; }
    }
}

もちろん、読み取り専用バージョンを使用する場合は、単純なキャストで十分です。これはまさにあなたのソリューションCが何であるかですが、私はそれを達成した方法を提供すると思いました

この質問を見つけて、まだ答えに興味がある人のために-今、さらされている別のオプションがありますImmutableArray<T>。私はそれがその後、より良いことだと思う理由は、これらはいくつかのポイントですIEnumerable<T>かReadOnlyCollection<T>。

• 不変であることを明確に述べています（表現力豊かなAPI）
• コレクションが既に形成されていることを明確に示しています（つまり、遅延的に初期化されておらず、何度も繰り返し処理してもかまいません）
• アイテムの数がわかっている場合のように、それはそのknowlegdeを隠していないIEnumerable<T>ん
• クライアント以来の実装が何であるかを知らないIEnumerableか、IReadOnlyCollect彼/彼女はそれが（他の言葉で、そのコレクションへの参照滞在変わらない一方で、コレクションのアイテムが変更されていないという保証はありません）決して変わらないと仮定することはできません

また、APiがコレクションの変更についてクライアントに通知する必要がある場合は、別のメンバーとしてイベントを公開します。

IEnumerable<T>一般的に悪いことではないことに注意してください。コレクションを引数として渡すとき、または遅延初期化されたコレクションを返すときに、まだ使用します（この特定のケースでは、アイテム数はまだわかっていないため非表示にするのが理にかなっています）。