がらくたにおける再生産性の雑感3

コンポーネント対応の件、なんとなく考えがまとまってきた。

コンポーネントと一口に言ってもライトウェイトなモノとヘビーウェイトのモノがある。そこには留意する。
しかしまあ、画面部品のほとんどはライトウェイトなものだ。これらはRAPの全てをメインスレッドに置くことになるだろう。
で、conductorとのやり取りも(メッセージの形で隠蔽するとは言え)イベントリスナーやコールバック関数を使って素早い呼び出しをするだろう。

ところで、こうなるとconductorにはたくさんのコンポーネントのRAPを捌く機能が要るわけだが、conductorから見ると「どのコンポーネントのreceptorから来た通知か」とか「どのコンポーネントのperformerに通知を渡すのか」と言ったオーバーヘッドが大きくなる。素早い呼び出しを志しても無意味になる。
各コンポーネント専用のconductorが有れば、比較的簡単に済む判断が、中央の単一のconductorが扱うと複雑になる。

結局はコンポーネント毎にconductorを持つ方が都合が良さげ。コンポーネントはRAPじゃなくCRAPを持つ。

「子コンポーネント」を組み合わせて構成された「親コンポーネント」なら、各「子コンポーネント」のconductorが「親コンポーネント」のconductorの子部品となるわけだ。
「親コンポーネント」にも独自のRAPが有るだろうが、「子コンポーネント」のreceptorが受け取ったイベントは「親コンポーネント」のreceptorが気にする必要はないってか気にするべきじゃないし、「子コンポーネント」のperformerが操作するDOMツリーは「親コンポーネント」のperformerはアンタッチャブルであるべきだ。

「親コンポーネント」のCRAPから見て、子コンポーネント」は独立してブラックボックス化されるべきだから、これでいい。
「親コンポーネント」からすれば「子コンポーネント」と必要なメッセージの授受が出来れば良いので、「親コンポーネント」のconductorと「子コンポーネント」のconductorがメッセージを通じて連動出来れば良い。

例えば「メイン画面」が親コンポーネントで、「メニュー部品」が子コンポーネントなら、メニューにカーソルがある時の処理は「メニュー部品」が考えれば良くて、「メイン画面」は例えばメニューから選ばれたアイテム選択の結果さえ得られれば良い。これは「メニュー部品」(のconductor)から通知を得れば問題ないわけだ。

とりま、このラインで考えよう。