oop - この機能をどのように抽象化しますか?

Question

次のクラスとその封じ込めに注意してください。

SectionItemList多くItemの sを持つを持っています

しかし、含まれItemている に基づく複雑なアルゴリズムに基づいて、 が別の色でレンダリングされるとしましょうSection.name。

この機能を抽象化するための適切な/最良の方法は何ですか? このような状況で発生する一般的な設計パターンはありますか? それとも、固有の設計に欠陥がありますか?

Answer 1

データ構造/モデルをロジックおよびそれらの処理から分離する必要があります。そうは言っても、アイテムSectionにそれを参照する参照を持たせることSectionにします。にを追加するときはItem、ItemListaddメソッドがItemLists Section（親）を参照し、参照をに設定するようにしItemます。ItemListのセッターについても同じSectionことが言えます。それぞれを繰り返してItem、を設定する必要がありSectionます。

あるいは、怠惰なセマンティクスとしてSectionのゲッターでセットを作成することもできます。これは、パフォーマンス統計ItemListの使用に応じて完全にあなた次第であり、これら2つのアプローチ間で異なります。Section

さらに、とを取り、Itemそれをレンダリングする方法を知っているレンダラーのいくつかの形式を記述Sectionします。ItemNameSection

セクション全体をレンダリングしたい場合もありますが、そのレンダラーを個別に記述し、を使用しItemRendererてそれぞれをレンダリングしますItem。

余談ですが、レンダリングされたバージョンとアイテムの両方の同期を維持し、プロパティを更新するイベント登録によって存在するバージョンと同期できるように、フォームを使用して実装も使用することをお勧めしIObservableCollectionますItem。適切に。INotifyPropertyChangedItemSectionSection

Answer 2

レンダリングは何ですか？これらすべての内部Sectionまたは外部にあるものの、Itemからsにアクセスする場合はSection、これ以上必要なものはありません。

にある場合は、それが何に属しているかItemを確認するか、取得できることを確認する必要があります（たとえば、検索できるIDを取得することで、循環参照の処理を難しくする言語で役立ちますが、それ以外の場合は不必要な手間はかかりません）。 。ItemSection

最初のケースでは問題が発生しないため、2番目のケースよりも明らかに優先されます。したがって、デザインパターンに最も近いのは、含まれているアイテムでこの種の作業を行っていることに気付いた場合は、それをコンテナに移動してみることです。 、またはそれらすべての外側。それを超えて、解決する必要のある問題はそれほど多くありません。

Answer 3

ItemRendererアルゴリズムを知っているクラスを構築し、Itemレンダリングしたいそれぞれへの参照とSectionそれが含まれている.

それぞれが属するセクションを知らせることも理にかなっているかもしれませItemんが、それでもItemRendererレンダリングの処理は任せます。