「イベントドリブンは拡張性が低い」のだろうか？

Prog

とまぁ「拡張性が低いだろ？」なんていわれてしまったのですが…そうなんですかねぇ？ むしろ私は「拡張性は高く、仕様変更にもまぁ対応しやすい」と思っているのですが…


拡張性が低いと主張された方は、メッセージ配信用のモジュールを作成し、メッセージがが届いた時には、どのモジュールのどの関数(モジュールに実装されているAPI)を呼ぶのかを管理を行う。そして、無駄をなくした方が良いと主張されました。なお、メッセージとAPIの対応は専用のツールで対応します。

イベントが発生した時の挙動は、一括集中管理ってことですが、これは私としては

  • 仕様変更の時に、各モジュールとメッセージ配信用モジュールのインターフェース関数が増減した場合、メッセージ配信用モジュールがごっちゃになってしまう可能性がある。（ツールは使っているのである程度はカバーできるとは思うのですが…*1）

と思うわけですよ。



で、好きの私の主張「イベントドリブンは良い…心が洗われる…」としては、ドリブンではイベントを必要する全てのモジュールへメッセージ送りつけ、モジュールは必要なメッセージだけ捉えて対応するワケじゃないですか。

この時、

  • 仕様変更としてイベントが増えたときは、メッセージの種類(ID)を増やすだけで対応でき、モジュール間インターフェース関数の増減は無い。 そして、モジュール側は必要な場合のみコードを変更すればよい。
    • 対応が必要なモジュールのみ手を加えればよい。
  • 仕様変更で、あるイベント通知が必要になった場合は、自分のモジュール内のメッセージ通知関数内で、case文ひとつ加えるだけでイベントの取得が出来てしまう。
    • 配信用モジュールで対応してもらう必要がなく自モジュール内で対応できるので、早急に対応できる。

などなど、良い点が色々あると思うんですけどなぁ。 メッセージに対する各モジュールの処理がそのモジュール内のみで完結してしまうと言うのは良いし、配信元も「なんか来たけど、テキトーに通知しておくから後よろしく」の対応で済むので楽だと思うし。



…まぁ、ウィンドウプロシージャの影響を強く受けてる考え方なのかもしれませんけれど…（ぉ


# ただ、前者の場合は確かに無駄が無くなるとは思います。無駄なメッセージ配信を行わなくて済みますからね。


なんか青い発言してるかしら…＾＾；

追記

知人のPGさんに「.NetFrameworkのEvent driven modeを参照するべし！」と連絡を受けてみたり。

情報 thx です。


…が、msdn のどこを見れば良いんだろう…（ぉ ＾＾；

*1:地味に良いツールなんだなぁ