やなど、さまざまなタイプのコレクションをプロパティとして公開するクラスがList<Address>ありSortedSet<string>ます。コレクション クラスは read-onlyperson.Address[3].City = "MyTown"であるべきであり、 やなどの更新用のコレクションを公開してはならないことを理解していperson.EmailAddresses.Add("foo@bar.tld")ます。これをサポートする C# パターンを探しています。
私のクラス (この例では Person など) が を実装しているため、私の要件は少し独特ですINotifyPropertyChanged。したがって、これらのコレクションに変更が加えられた場合は、コンテナー オブジェクト (人物) でイベントを発生させて、クライアント アプリケーションに通知したいと考えています。ObservableCollection<T>を使用できることはわかっています。そのために、ソートされたストレージを維持する派生クラスのthisおよびthisSortedSetのような例があります。この Person クラスを利用する他の開発者のために、自分のプロジェクトにカスタム クラスを追加しないようにしています。クライアント アプリケーションが他の構造を操作する必要性を減らすために、CLR クラスのみを公開したいと考えていますが、それは必須ではありません。 .
このソートされたストレージの問題に対するほとんどの解決策は、「ソートされたデータを保存せず、クライアントのビューに任せる」ことですが、このクラスを使用している開発者はソートの共通機能を残しており、それぞれが独自の実装を作成するために個別の時間を費やしています。別のテクノロジ (WPF コンポーネント、LINQ など) で。この例では、Personクラスは別のよりプリミティブなクラスをラップします。たとえば、私のプロパティには配列SortedSet<string> Emailを作成するセッターがあります。EMAIL[]その配列をシリアル化すると、従来の目的で並べ替える必要があり、基本型が並べ替えられている場所で、並べ替えられたジェネリック コレクションを公開したいと考えています。
また、コレクションの内容が変更されたときに PropertyChanged イベントを発生させるべきではないことも読みました。この場合、クライアント アプリケーションは、このオブジェクトになんらかの変更が加えられるたびに知る必要があり、それを行うべきではない理由についての議論は、実際にそれが必要であるという現実と一致しません。
要約すると、コンテナー オブジェクト内にカプセル化されたコレクションを変更するための一貫した C# デザイン パターンを探しています。コレクションが並べ替えられる場所、コレクション要素が値型または参照型である可能性がある場所、およびクライアント アプリケーションがこのオブジェクトを使用する場所です。すべての変更の変更通知を受け取る必要があります。
この時点で、すべてのコレクション型に対してこのクラスの一貫した API を作成し、Personコレクション オブジェクト全体をおそらくジェネリック CLR コレクションとしてではなく、厳密に型指定されたクラスとして取得し、インスタンス プロパティをそのようなオブジェクト、要素を設定し、それをクリアします。しかし、私はむしろ、一般的なゲッター/セッターを使用してこれらすべてを実行したいと考えています。