イベントドリブン（続き）

事は簡単。イベントと処理(やりたい事)の間を繋ぐ橋を作ればいいのです。具体的には処理(やりたい事)を中心に、この処理はどのイベントから起動されるのかを指定し、どういう状態の時に実行してよいかをまとめておく。こうすればこの「橋」は、指定された(複数の)イベントを取って、現在の状態を調べてやりたい処理を起動してよいなら起動する。すっきりまとまってるじゃないですか。これでインピーダンス解消！
...だが、ちょっと待って欲しい(朝日新聞風;p)。実際にはそううまくいきません。
オブジェクト指向のプログラムでは個々のオブジェクトの責任が厳しく分割されており、身の回りのオブジェクト以外の情報を得ようとしたら、まず身の回りのオブジェクトが代理して次の情報元近くのオブジェクトに依頼して、辿っていって、また応えを戻してもらうというバケツリレーが必要になります。そして、処理起動判定の判断材料となる現在の状態は、往々にして橋からは遠い彼方にしかありません。（これを例示しなければいけないと思いますが、長くなるのでまたいずれ。）それに、素直にバケツリレーすればいいじゃないかと言われるかもしれませんが、それが果して便利な設計方針なのか疑問が残ります。
これは結構本質的な問題です。要するに「橋」を作ろうと画策する事自体がオブジェクトの責任隠蔽を破壊する行為なのです。
そりゃそうなのかもしれません。オブジェクトが「自分で判断して自分でやる！必要ならちゃんと客先にもメッセージ投げるから！」といっているのに橋は、「予め俺が判断してやるからお前は何も考えずに言われた通り作業しろ！」と、まるで部下と上司のケンカのような事になっている訳です。
さて、振り出しに戻りました。どうすればいいのでしょう？実は最初の問題は無視すべき問題なのかもしれません。オブジェクト指向素人な私には解法が思いつきませんが、もっといい方法があるのだと思います。
ただ一つ言えることは、amthingはこんな問題は抱えていないという事です。