CRAPモデルの概要

CRAPモデルについて

概要

オブジェクト指向的概念のMVCをメッセージ駆動概念に置き換える試み。

(C)「コンダクター(conductor)」

メッセージを調整して各ユニットと授受する指揮者

(R) 「レセプター(receptor)」

画面からの入力を受け取りコンダクターに受け渡す

(A) 「アクター(actor)」

コンダクターの指示で各種の処理を行う

(P) 「パフォーマー(performer)」

コンダクターの指示で画面表示を行う

以上の各ユニットから構成される。

各ユニット間の関係

   receptor → conductor → performer
                  ⇅
               actor(s)

各ユニットの役割

コンダクター(conductor)

指揮機能。後述する各ユニットとの通信を指揮する。各種イベントの制御を行う。後述のレセプターやアクターとの通信等で発生するイベントを制御する。非同期処理の競合を調整したりするのも役目になると思う。調整されたイベントを後述のアクターやパフォーマーに通知する。

レセプター(receptor)

入力機能。主に画面入力(DOM)で発生するイベントを受け取りコンダクターに通知する。

アクター(actor)

状態遷移の具体的な処理を行う。通知されたイベントと自分の状態(これはオブジェクト、てかプロパティか？)に基づく処理を行う。一般的なプログラムのイメージ。必要に応じて複数のアクターが連動する。別のアクターからの要求を受け付けたり、処理を依頼することになるが、これはコンダクターを介して行う。子コンポーネント(それ独自のCRAPで構成される)も親コンポーネントのアクターとして振る舞う。

パフォーマー(performer)

出力機能。ビューの生成や表示を行う。HTML5+CSSのイメージ。フレームワーク的には、アクターからの(コンダクター経由での)要請により、DOMツリーの生成、変更、削除を行う。CSSOMも動的に制御する。

コンポーネントのネスティング

再生産性を考慮し、コンポーネントはより小さなコンポーネントを組み合わせ、それに付加機能をつける形での開発を想定する。

• 各コンポーネントは独自のCRAPを持つ。
• 子コンポーネントは親コンポーネントから独立しており、その挙動はブラックボックスとなる。
• 子コンポーネントは、親コンポーネントに必要な情報のみ通知する。
• 親コンポーネントは、子コンポーネントに必要な情報を通知する。
• 親コンポーネントから見ると、子コンポーネントのコンダクターが自分のアクターとなる。

例)

• 親コンポーネント→メイン画面
• 子コンポーネント→メニューバー

の場合。
「メニューバー」にカーソルがある時の処理は「メニューバー」自身が行えば良い。
プルダウンメニューの表示やメニューアイテムの選択イベントの受信、選択されたアイテムの取得等の機能は「メニューバー」単独で解決できる。
「メイン画面」はそれらを知る必要はなく、また干渉するべきではない。
「メイン画面」は例えばメニューから選ばれたアイテム選択の結果さえ得られれば良い。
これは「メニューバー」(のconductor)から通知を得れば足りる。

各ユニットが稼働するスレッド

役割	スレッド	概要
conductor	メイン+WORK	各ユニットのイベント通知(メッセージ)を受け付けて非同期に稼働する役割なので、主にメインスレッドとは別のスレッドで稼働する。後述するがperformerがメインスレッドで稼働する関係上、一部機能はメインスレッドに置く
receptor	メイン	UIによるイベントはメインスレッドで発生するので、メインスレッドで稼働する
actor(s)	メインorWORK	メインスレッドで動かすには負荷が大きすぎるものは別スレッド化する。また、バックエンド・サーバーとの通信など待ち合わせが発生する処理も別スレッド化する。ライトウェイト・コンポーネントなど処理が軽くてスレッドを生成するコストが高く付く場合はメインスレッドで動かす
performer	メイン	出力機能としてはDOMやCSSOMを操作しなければならないが、JavaScriptの仕様上、メインスレッドでしかこれらを扱えないので、メインスレッドに置く