コンテンツにスキップ

イベント駆動型プログラミング

出典: フリー百科事典『ウィキペディア(Wikipedia)』

イベント駆動プログラミング(イベントくどうプログラミング、: event-driven programming)とは、ユーザー側の操作による受動的なイベントの発生によって、コンピュータ側の能動的なプロセスの実行とプログラムフローの選択が決定されるというプログラミングパラダイムである。イベントドリブンとも邦訳される。グラフィカルユーザーインターフェース(GUI)ソフトウェアでよく用いられており、ユーザー入力に対するレスポンス出力の実装に適している。デバイスドライバプログラムでも多用されている。Webアプリケーションでも並行計算を実現するための非同期処理で活用されている[1]

ここで言うイベントとは、マウスクリックキーボード押下によるユーザー操作、センサーシグナル[要曖昧さ回避]受信によるハードウェア入力、走行スレッドや発生トランザクションからのメッセージ受信を指している。プロセスの実行とは、スレッドの開始や手続き/関数の呼出しを指している。

特徴

[編集]
イベントフロー図

規則型(宣言型)のイベント駆動型プログラミングにおいては、規則の条件部が満たされ指定されたイベントが発生すると、その規則が実行される。このような規則を ECA規則 (event-condition-action rule) という。例えば為替レート換算であれば

  • プログラムの起動直後 → 換算前の金額を1に設定する
  • 換算前の通貨単位と変換後の通貨を「選択」する → 換算前の金額とそれぞれの通貨を為替換算サービスに送る
  • サービスから為替レートを「受け取る」→ 換算前の金額とレートから換算式を組み立てる。
  • 入力欄に換算前の通貨の金額を「入力」する → 入力された金額を換算前の金額に設定する
  • 換算前の金額が「設定される」→ 換算式を利用して換算結果を提示する

といった規則を用意しておけば、利用者としては

  • 通貨単位だけ選択済みで金額が未入力ならば、例えば1円あたり何ドルかが得られる
  • 金額だけを変更することで、選択しておいた通貨間で換算を次々に行える
  • 金額をそのままにしても、通貨を選ぶ度にすぐに換算される。
  • 入力を「確定する」という余計な手順を省ける(リアルタイム性)

というメリットを享受できる。ここで挙げた例は、データや状態の変化に反応して処理が起動されるリアクティブプログラミング英語版と呼ばれる。

手続き型のイベント駆動型プログラミングにおいては、まず各イベントに対応する処理を記述した手続き(サブルーチン、関数、あるいはメソッド)を、システムあるいはアプリケーションフレームワークに登録する。この手続きはイベントハンドラー (event handler) と呼ばれ、イベントが発生したときにシステムあるいはアプリケーションフレームワークによって呼び出される(コールバックされる)。イベントの待機中(アイドリング時)の処理はシステムに任せる。

一般的に、グラフィカルユーザインタフェース (GUI) を使用するオペレーティングシステムアプリケーションソフトウェアでは、イベント駆動型プログラミングを利用している。マウス操作やキーボード操作といったユーザーからの入力や、システム状態の変化・変更といった各イベントに対する処理を統一的に記述することができる。

イベント駆動型プログラミングを行うメリットは、アプリケーションを作成する際に、必要なイベントハンドラーにのみ処理を書けばよい、ということである。イベントを待機するプログラム構造自体はどのアプリケーションもほぼ共通であり、結果として、アプリケーションフレームワークによるプログラム構造のブラックボックス化と再利用がしやすくなり、アプリケーションプログラマーが記述しなければならないコード量が減る。処理の記述をハンドラーごとに分けるので、プログラムの見通しも良くなる。

用語と解説

[編集]
イベント
「キーボードのキーを押した」、「時計がある時刻になった」などの、プログラムの流れとは別に発生する事象。または、その事象に関する情報を含んだメッセージを指す。 →イベント (プログラミング)
イベントハンドラー
イベントが発生した際に実行すべきサブルーチンのこと。イベントフック、イベントリスナーなどの呼び方がある。
トリガー
イベントを発生させるきっかけ。プログラム内部でイベントを起こすことを「イベントをトリガーする」と表現することもある。
イベントディスパッチャー
発生したイベントをイベントハンドラーに振り分ける機能のこと。
イベントキュー
複数のイベントが連続して発生した場合に、それらのイベントを待ち行列として保持するデータ構造。イベントの発生間隔が短く、次のイベントが発生するまでにイベントハンドラーの処理が間に合わない場合にバッファとして用いられる。→メッセージキュー
イベントループ
イベントを待機するループを持つ機構。イベントループ内にイベントディスパッチャーを持つ構造が一般的である。メッセージループ、メッセージポンプとも呼ばれる。

実装

[編集]

イベントで駆動される処理はイベントハンドラーに記述されるが、その実装方法は開発者に一任される。処理の特性(実行内容、規模/複雑性)に合わせた典型的なイベントハンドラ実装パターンが存在する。以下に各パターンを挙げる。

Fluxパターン

Flux(フラックス[注釈 1])は、Actionを介したブロードキャスト型メッセージパッシングによるパターンである。状態管理をStoresに委譲し、イベントハンドラはActionの発火に特化する。イベント側と状態管理(ビジネスロジック)側を疎結合にできる利点を持つ。またActionメッセージを保持・記録して取り回すことができる。

UIが関わる実装としては、Reduxデファクトスタンダードである[2]

Commandパターン

Commandパターンはオブジェクト指向プログラミングを用いたパターンである。実際の処理をCommandオブジェクトへ委譲し、command.Execute(コマンド実行)インターフェースをイベントハンドラ内で叩くことにより、イベントハンドラ側と処理側を疎結合に出来る利点を持つ。またCommandオブジェクトを保持・記録して取り回すことができる。

脚注

[編集]

注釈

[編集]
  1. ^ アプリケーションのデータフロー管理のためのアーキテクチャパターン。

関連項目

[編集]

外部リンク

[編集]