KVO, Key-Value Observing

前回のKey-Value Coding自体は、なんでそんなめんどくさいアクセスの仕方をしなきゃならんのだ、とも思える。
しかしKey-Value Observingは結構考え方が変わる。設計自体変わるかもしれない。

Key-Value Codingに準拠したメソッドの組は、プロパティとして扱える。
そして、このプロパティに対しては、Key-Value Observingが可能だ。
具体的に言うと、hogeというプロパティを持つオブジェクトがあるとする。
そこに、別のオブジェクトがaddObserver:forKeyPath:options:context:というメッセージを送る。
すると、hogeというプロパティが変更されたときに、別のオブジェクトの方にobserveValueForKeyPath:ofObject:change:context:というメッセージによって変更とその内容が通知されるのだ。

じゃあ「変更」ってどういうことだろうか。

• まず、setValue:ForKey:が呼ばれたとき
• setHoge:が呼ばれたとき
• オブジェクトにwillChangeValueForKey:とdidChangeValueForKey:が送られたとき

そういうことです。他のオブジェクトがsetHogeされたのを感知できるのだ。特殊なコードを書く必要はない。Observerパターンなんて考えなくてよろしい。

ではThousandではどう使っているのか？
まずBindingの代わりとして使っている場面がある。ていうかBindingはKVCとKVOを組み合わせたものだから、当然と言えば当然だけど。
次に、まあBindingの代わりとも言えるんだけれども、2chのスレッドを読み込んでWebViewに表示させるところで使っている。
ThousandではT2Threadというオブジェクトが2chのような掲示板のスレッドを表しているんだけれど、これはloadメッセージで自己読み込みを開始する。つまり自分に必要なURLを割り出し、ネットに接続してdatをダウンロードし、レスの集合、resArrayをsetする。
普通ならloadメッセージの引数に、何らかのリスナーを渡して途中経過とか完了とかを通知するんだと思うけれども、今回はそれをやっていない。知りたいならresArrayをObserveしたり、progressをObserveしろ、というわけだ。

そういうわけで、KVCやKVOを使うとインターフェースに依存しないコーディングが出来る。これが従来のやり方と比べてどういう長所、短所があるのかはこれからじっくり見極めてみたい。