言語ゲーム

とあるエンジニアが嘘ばかり書く日記

Twitter: @propella

ペトリネット、関数、PollingObserver (eToys モデルとオブザーバーパターンの融合その2)

イマイチ受けの悪かった PollingObserver の話ですけど、きっとこんな基本的なアイデアは他に誰か考えた人がいるはずだと風呂でよく考えたら、骨子はまんまペトリネットのサブセットだという事が分かった。

PollingObserver の定義

  • 一つのモデルと一つ以上のビューがある。
  • ビューはモデルに依存しているが、モデルはビューの事を知らないというのを実装したい。
  • ビューはモデルに今の状態を尋ねる。その返事はすぐに返らない。
  • モデルの状態が変わると、尋ねてきたビュー全てに新しい状態を答える。

PollingObserver の性質

  • Observer と違う所は、ビューがモデルにずっと登録されるのではなく、一度限りの関係(最適化の為に密かに登録するのはは在り)。
  • Polling と違う所は、尋ねてもすぐに答えが返らない点。
  • 関係が一対一の時はパイプやネットワーク入出力関数と同じ動作。

ペトリネットというのは、向きのあるパイプが縦横無尽に繋がれている中を玉が転がるようなモデルの事で、玉が繋ぎ目の入口に到着するとあるルールに基づいて出口の数だけ玉がそれぞれ出て来るモデルを言うらしい。PollingObserver は入口がモデルの変更を表す信号で、出口がビューに伝えるデータと考える事が出来る。モデルは一つと決まっているので、入口が一つの場合のサブセットと考える。

本当に依存をペトリネットのように考えて、複数のモデルに依存するビューというのも面白いけど、GUI の場合複数のモデルに依存していてもそれぞれのモデルが更新するたびに一度ずつビューが書き換わると思うし、ややこしいので考えない。

また、PollingObserver を関数の裏返した形と考えるのも面白い。関数もまた、入口と出口があるブラックボックスという風にモデル化されるけど、一旦入口に入った状態から着目して、出口から出ようと待ってる状態を PollingObserver だと考える事が出来る。これについては継続がらみで他に面白い話が待っているような気がするのでゆっくり考える事にする。