簡単に言うと
監視者(Observer)と監視対象(observable)のオブジェクトがあって
監視対象の値が変わったときに監視者(Observer)のメソッドを呼び出して通知して上げること。
*ここが一般的な考えと違う。監視者が自分で呼ぶわけではない。
それではもう少し説明
* 私はiOSエンジニアですが、見つけた記事が.NET向けだったのでその方向で進めさせていただきます。
学ぶ理由
そもそもObserverパターンを学ぶ理由は、RxSwiftを勉強しようと思ったけどまったくわからず、調べてるうちにオブザーバーパターンをまずは知ったほうがわかりやすいという記事にあたったからです。
*そもそもデザインパターン全く知らんし
概要
Rx(Reactive Extension)の根幹となる考え方。
監視対象のオブジェクトに観測者オブジェクトを登録して、監視対象が変化したときに観測者のメソッドを呼び出すことで観測者に変更を通知する。
監視対象は観測者(の型)を直接知らないようにすることが重要で、そのために一般的にインターフェースが利用され、.NET Framework4 では監視対象のインターフェースとしてIObservableが観測者のインターフェースとしてIObserverが使われた。
基本的説明
IObservable(←インターフェース)
Subscribeメソッドのみを持つ。Subscribeは通知先を登録するメソッド。
引数として変更の通知先であるIObservetを要求。戻り値はIDisposableで、そのDisposeメソッドを呼び出すことで通知を止められるようにする。IObservetの具象(インターフェースを採用した)クラスではその通知先を記憶(登録)することが求められる。変更の通知を行う必要がある場合、Subscribeメソッドで登録されたすべてのIObserverの特定のメソッドを呼び出す。
swiftで書くならこんな感じ?
func subscribe(observer: IObserver<T>) -> IDisposable
IOserve(←インターフェース)
これらはIObserverで定義されているメソッドでIObservable(= 監視対象)がこれを呼ぶことで通知する。
状態が変化したことを通知する際はOnNextを呼ぶし、状態変化の通知(つまりOnNext)が完了したことを通知するにはOnCompletedを呼ぶ。また何らかのエラーが発生したことを通知する際にはOnErrorを呼ぶ。
このようにIObservable(= 監視対象)は自身の状態の変化に応じてこれらを適切に使い分けて呼び出す必要が求められ、
IObserverではそれに適切に応答することが求められる
いい記事みつけた
以上が基本的な説明。
間違っていたらすみません。
最後にわかりやすい記事をみつけたので貼って終わり。
https://53ningen.com/rxswift-observable/
要約するにおそらくそもそもはプロパティ監視で通知をしていたけれど
・一箇所でまとめて呼ぶことができない。
・通知先のオブジェクトが変更されたとき、通知元の実装も変更しなければならない。
・通知先のオブジェクトの種類が増えるとき、通知元の実装も追加しなければならない。
といった問題があったためにObserverパターンが生まれたのだと思う
で、そのObserverパターンには2種類あるらしい
① pull型Observerパターン
→ 上記の問題(複数の異なる通知先に状態変化を通知したい)は解決した。
→ しかし、状態が更新されたことを通知するのみで、どのような値に更新されたのかはObservableのプロパティなどを参照しにいかなければ知ることができない。
→ したがって、現実的には更新された値を参照するために、Observer も Observable の参照を何らかの方法で取得できる状況にする必要があり、相互参照する構造になってしまいます。
② push型Observerパターン
①の問題を解決するのがpush型Observerパターン
通知する際に更新後の値を渡してしまう構造にしたもの。
Rxはこのpush型Observerパターンに限りなく近い・・・?