IT Office Nishimiyahara

個人用スマホから商用プログラミングまでなんでもお任せ下さい

Mojoliciousでイベント駆動型プログラミングしてみた(その2)

      2014/03/22

@nqounetです。

前回に引き続き、イベント駆動型プログラミングについて考えながら書いてみました。

前回は、Mojo::EventEmitterのSYNOPSISから考えてみましたが、イマイチ腑に落ちないというか、しっくりこない感じで消化不良だったので、もう少し違う角度から見てみようと思います。

フックとしてのイベント

RPGというか、具体的にはドラゴンクエストでは、毒を受けた状態だと数歩歩くごとに毒のダメージを受けます。

歩くというイベントに対して、毒の状態の場合にダメージをうけるようなプログラムを考えてみました。

多少無理矢理な気もしますが。

歩く$man->walkと、walkというイベントが発生し、そのイベントを購読した状態が毒を受けた状態で、購読をしていない状態がステータス異常が特にない、という状態です。

普通(?)に書くと以下の様な感じかなと思います。

Humanクラスが毒の状態を持っていて、その状態を歩く都度確認し、毒状態であればダメージ、そうでなければ何もしない、という感じです。

拡張性を考えれば毒の状態をHumanクラスが持つのはまずいですが、今のところはそこまで考えないことにします。

当初は、Humanクラスの中でsayしていたのですが、sayが分散するのを防ごうと思った時、歩くというイベント自体よりも、ログの方にEventEmitterの強みを感じました。

通常、呼び出した先で何か異常が起きた時、それを呼び出し元で対処するのは難しいです。

EventEmitterを使った場合、Humanクラスのmessageイベントを購読しておくことで、Humanクラス内で発生させたmessageイベントを呼び出し元で簡単に扱うことができます。

また、その際、呼び出し元に対してメッセージやオブジェクトを返したりせずに、その場でイベントを発生させれば良いのでプログラムがわかりやすくなったと感じました。

エラー発生時の処理としてのイベント

そこまで考えた時に、try ~ catchのことを思い出しました。

tryは、致命的なエラーが発生するかもしれないコードを実行するときに、そのエラーをトラップして異常終了しないように使います。

もしかすると、try ~ catchではなくerrorイベントを購読してエラーをトラップする、というのがイベント駆動型の一つの使い所としてわかりやすいような気がしました。

respo

respo link

ZenBackWidget

 - 情報技術について , , ,