6. 事例:Observerパターン

問題

ある一つのオブジェクトの状態変化に対し、他の複数のオブジェクトが同時に依存している場合がある。例えばあるモデルのデータの最新情報を表示するビューは、モデルの状態変化に応じて再表示を行わなければならない。これら複数の異なるビューが、一つのモデルを参照している。
モデルの状態とビューの表示を一貫性のある形にするには、相互の協調が不可欠だが、モデルがあらかじめ多様に発展していくビューの全て知っており、それぞれに応じて再表示の要求を送るのは困難である。またモデルがビューに直接更新を要求すると、モデルとしてのクラスの独立性が失われてしまう。

制約

• ある一つのオブジェクトの状態変化を、複数のオブジェクトに通知しなければならない
• 状態変化を受け取るオブジェクトは多様なものになる可能性があり、状態変化を起こす側では、あらかじめそれを知ることができない
• あるタイミングで、状態変化を通知されていた側が、その通知を必要としなくなる場合がある

解決策

あるオブジェクトの状態変化を受け取る側は、変更を観察するもの、Observerとして抽象的にとらえられる。変更の起こる側は、Observerにとって関心のあるSubjectである。ObserverとSubjectといった抽象レベルで、Subjectに対するObserverの登録、また登録されたObserverに対する通知の仕組みを用意することで、相互の密な結合を防ぐ。

構造

以下のような構成要素から成り立つ

• Observerクラス
  • Subjectの状態変化を監視する
  • Subjectからの状態変化に対し通知受け取りのインターフェースを提供する
• Subjectクラス
  • Observerを登録、削除する機能を提供する
  • 登録されたObserverに対して状態変化を通知するインターフェースを提供する
• ConcreteObserverクラス
  • ConcreteSubjectを参照している
  • ConcreteSubjectからの状態変化に対し、通知を受け取り、自身を更新する具体的な処理を実装する
• ConcreteSubjectクラス
  • ConcreteObserverにとって有益な情報を保持する
  • 状態変化の際にSubjectで規定された、変更通知操作を呼び出す

以下のようなクラス図となる。

振る舞い(協調関係)

登録

1. 関心のあるConcreteSubjectに対してConcreteObserverの登録(addObserver:)が行われる
2. ConcreteSubjectは自身のリスト(dependents)にConcreteSubjectを追加する

通知

1. ConcreteSubjectの状態が、更新操作の起動により変化する。
2. ConcreteSubjectは自身の状態変化に伴い、通知用の操作(changed:)を起動する
3. ConcreteSubjectに登録した全てのConcreteObserverの通知受け取り操作(update:)が起動される
4. 通知受け取り操作でConcreteObserverは最新ConcreteSubjectの最新状態を取得し適切な処理を行う

以下のようなコラボレーション図となる。

効果、副作用

• ObserverのSubjectへの登録、登録されたObserverへのSubjectからの通知が、抽象レベルで定義されており、ConcreteSubjectのConcreteObserverに対する結合の度合いが低くなる
• Subjectに対するObserverの登録により、同時に複数のObserverに対し変更の通知が可能になる
• Subjectに対する変更に関心がなくなったObserverは、登録から削除することによって変更の通知を受けなくすることができる
• 登録された全てのObserverに対して通知されるため、Subjectの状態の変更が非常に多い場合には、Observer側の更新受け取り動作が必要以上に起動される可能性がある
• Subjectの状態変化に対してObserverが最新のSubjectの最新状態を取得するが、Subjectのどの属性についての変更かを示す関する情報がないと、全ての属性の値についてObserver側が取得せねばならず、全体の効率を落とすことになる。

別名

Publisher-Subscriber

(Subject、Observerにそれぞれ該当する。定期購読申込者に最新の雑誌が届く連想から)

Dependents

(ObserverはSubjectに対し、通常の関連に比べ結合度の弱い依存関係を持つため)