リストを適切に公開<T>？

Question

私はプロパティでList<T>を公開するべきではないことを知っていますが、それを行う適切な方法は何ですか？たとえば、このやって：

public static class Class1 
{ 
    private readonly static List<string> _list; 

    public static IEnumerable<string> List 
    { 
     get 
     { 
      return _list; 
      //return _list.AsEnumerable<string>(); behaves the same 
     } 
    } 

    static Class1() 
    { 
     _list = new List<string>(); 
     _list.Add("One"); 
     _list.Add("Two"); 
     _list.Add("Three"); 
    } 
} 

は私の発信者は、単にList<T>にキャストバックすることが可能になります。

private void button1_Click(object sender, EventArgs e) 
    { 
     var test = Class1.List as List<string>; 
     test.Add("Four"); // This really modifies Class1._list, which is bad™ 
    } 

私は本当に不変List<T>をしたいのであれば、私は常に新しいリストを作成しなければならないでしょうか？

public static IEnumerable<string> List 
    { 
     get 
     { 
      return new ReadOnlyCollection<string>(_list); 
     } 
    } 

しかし、私のリストには、誰かがそれにアクセスしようとするたびにクローン化されるよう、パフォーマンスのオーバーヘッドがある場合、私は心配している：例えば、これは（テストでは、キャスト後にnullである）動作するようですか？

Answer 1

使用AsReadOnly()からsee MSDN for details

Answer 2

はい、いいえ。新しいオブジェクトが作成されるため、パフォーマンスのオーバーヘッドが発生します。いいえ、あなたのリストはクローンされておらず、ReadOnlyCollectionでラップされています。

Answer 3

プロパティは、実際に諸悪の根源ではないようList<T>を公開。特にfoo.Items.Add(...)のような予期される使用が許可されている場合。

public static IEnumerable<T> AsSafeEnumerable<T>(this IEnumerable<T> data) { 
    foreach(T item in data) yield return item; 
} 

しかし、現時点では、あなたの最大の問題は、スレッドセーフである：

あなたはAsEnumerable()にキャスト安全な代替を書くことができます。静的メンバーとして、特にASP.NETのようなものに大きな問題があるかもしれません。でもReadOnlyCollection既存のリストの上には、この苦しむでしょう：

 List<int> ints = new List<int> { 1, 2, 3 }; 
     var ro = ints.AsReadOnly(); 
     Console.WriteLine(ro.Count); // 3 
     ints.Add(4); 
     Console.WriteLine(ro.Count); // 4 

だから、単にAsReadOnlyとされるラップないあなたのオブジェクトは、スレッドセーフにするのに十分な。 コンシューマのデータを保護するだけです（ただし、同期またはコピーを行わない限り、他のスレッドがデータを追加している間にデータを列挙できます）。

Answer 4

複製のオーバーヘッドを心配する必要はありません。つまり、ReadOnlyCollectionでコレクションをラップすると、でなく、クローンになります。ラッパーを作成するだけです。基になるコレクションが変更されると、読み取り専用バージョンも変更されます。

新鮮なラッパーを繰り返し作成することを心配する場合は、別のインスタンス変数にキャッシュすることができます。

Answer 5

クラスに他の目的がない場合は、リストから継承し、addメソッドをオーバーライドして例外をスローすることができます。

Answer 6

列挙体が途中でコレクションが変更された場合、AsEnumerableおよびReadOnlyCollectionに問題があります。これらはスレッドセーフではありません。それらを配列として戻して呼び出し時にキャッシュする方がはるかに良い選択肢になります。例えば

、

public static String[] List{ 
    get{ 
     return _List.ToArray(); 
    } 
} 

//While using ... 

String[] values = Class1.List; 

foreach(string v in values){ 
    ... 
} 

// instead of calling foreach(string v in Class1.List) 
// again and again, values in this context will not be 
// duplicated, however values are cached instance so 
// immediate changes will not be available, but its 
// thread safe 
foreach(string v in values){ 
    ... 
} 

Answer 7

あなたがIEnumerableをとしてあなたのリストを公開した場合、私は戻ってリストにキャスト発信者を心配しないでしょう。クラスのコントラクトで、IEnumerableで定義されている操作だけがこのリストで許可されていることが明示的に示されています。したがって、あなたは暗黙のうちに、そのリストの実装がIEnumerableを実装するものに変わる可能性があることを暗示しています。

Answer 8

私は以前同様の質問を：私はあなたが内部的にList<T>を使用することをお勧めします、とCollection<T>またはIList<T>としてそれを返すということに基づいて

• Difference between List and Collection (CA1002, Do not expose generic lists)
• Why does DoNotExposeGenericLists recommend that I expose Collection instead of List?

を。または、それを列挙するだけで、そのような追加または防御が必要ない場合は、IEnumerable<T>です。

あなたが戻ってきたものを他のものに投げ入れることができれば、私はただ気にしないと言います。人々があなたのコードを意図していない方法で使いたいなら、何らかの方法でコードを実行することができます。私は以前これについても質問をしていましたが、賢明なことはあなたが意図していることを明らかにすることだと言います。人々がそれを別のやり方で使うのであれば、それは彼らの問題です：p関連する質問：

• How should I use properties when dealing with List members（特にthis answer）
• Encapsulation of for example collections