クラス、、、を持っているContainerとItem、Propertyアイテムのプロパティが変更されるたびにコンテナに通知されます。
コンテナはアイテムの所有者であり、プロパティに従ってアイテムを適切に管理するための情報が必要です。
私はまだ2つのオプションを考えました：
私の意見では、オブザーバーパターンはそのタスクには重すぎるようです。プロキシオブジェクトはうまく機能する可能性がありますが、その場合、プロキシから実際のオブジェクトに呼び出しを転送する必要があるため、DRYの原則に違反します。
要件は、詳細がユーザーから隠されていることです。何らかの関数などを呼び出す必要がないことupdate_item()、つまり、コンテナをユーザーに通知する責任を与える必要があります。これは、使用上の問題につながる可能性があります。
このような単純なケースでは、 を使用する理由がわかりませんObserver。anは一度に 1 つのコンテナーにしか入れることができないため、 a が配置されているコンテナーへの参照またはポインターをItem与えるだけです。Item
一部Propertyの変更がそのポインターを介してItem通知できる場合Container
Observerpattern は、多くのオブジェクトに通知する必要がある場合に役立ちます。
編集
インターフェイスと非常にきれいなデザインを使用してすべての単純なものを作成することも、あなたに害を及ぼす可能性があります。からの引用は、zen of Python私が意味することをよく説明していると思います：
Special cases aren't special enough to break the rules. //make Interfaces
Although practicality beats purity. //but not everywhere
したがって、純粋さと実用性のバランスを取る必要があります
最も理解しやすく維持しやすく、特殊なコンポーネントの作成を最小限に抑える必要があるパターンを使用する必要があります。私が作業している環境 (objective-C) では、オブザーバー パターンはそれほど複雑ではありません。また、通知要件が変更された場合にも柔軟に対応できます。
アンドリューの答えは、より単純なイベントです。オブジェクト間の直接通信には、プロキシの発明や通知処理のオーバーヘッドは必要ありません。ただし、将来必要になった場合に備えて、柔軟性は低くなります。
「重すぎる」の意味がわかりません。おそらくあなたはそれを説明することができます。
前に述べたように、オブザーバーはここではかなりやり過ぎですが、解決策は非常に簡単です。イベントを「バブルアップ」するだけです。