つまり、リストを含むオブジェクトは、概念的には、データを格納するための有効な手段を持つ責任があります。つまり、必要なときにリストをインスタンス化する責任があります。
オブジェクトがオブジェクトのコレクションを表すように設計されている場合、新しいオブジェクトが複数のタイプのコレクションの「ラッパー」になることが目的の一部でない限り、オブジェクトがオブジェクトを格納するために実際に内部で使用するものをすべて維持する責任があります。内部で使用されるコレクションのタイプに基づいて動作をカスタマイズできます。
リストを考えてみましょう。配列を内部的に使用してデータを格納し、必要に応じて新しいオブジェクトを格納するために配列のサイズ変更を処理します。リストについてそれを知る必要はありません。概念的には、要素の挿入と削除を可能にする、順序付けられたインデックス付きのコレクションです。リンクリスト、赤黒木などを使用して実装できた可能性があります。それらは、パフォーマンスと複雑さに影響を及ぼします。
適切なケースに戻ります。追加のプロパティを持つリストであることが意図されているオブジェクトは、その内部データ構造を非表示にする必要があります。ユーザーは、そこに要素を保持しているリストがあることを知る必要はありません。つまり、オブジェクトは、それ自体の内部データ構造をインスタンス化する方法を知っている必要があり、呼び出し元が内部リストに作用する新しい要素を挿入するために使用するメソッドを公開する必要があります。
唯一の例外は、他のクラスのサブセットのいずれかに適用できる新しい機能を追加する「ラッパー」の例外であり、特定の使用法で新しいクラスを「ラップ」するクラスをユーザーが指定できるようにすることが重要です。例はBlockingCollectionです。これにより、コレクションに対して同時操作を実行しているスレッドを、その操作を実行することが有効で安全になるまでブロックする機能が追加されます(たとえば、コレクションが空の場合、BlockingCollectionからアイテムを取得しようとするスレッドはブロックされます。別のスレッドが何かを追加するまで)。作成時に、BlockingCollectionがIProducerConsumerCollectionインターフェイスの特定の実装を使用するように指定できます。ほとんどの場合、同じ名前空間に組み込まれている「同時」コレクションの1つになります。ConcurrentBag、ConcurrentQueue、ConcurrentDictionaryなど。この場合でも、「デフォルト」オプションがあります。使用する内部Concurrent構造を指定せずにBlockingCollectionオブジェクトをインスタンス化でき、オブジェクトはデフォルトでConcurrentQueueになります。