memo/20110516
created 2011-05-16 modified 2011-05-16
node.jsについて思うこと
ソフトウェア構築のノウハウがまた一つ、進歩したのだと思う。
「第二次イベントドリブンブーム」と名前をつけたい。
つまり、呼ぶ側、呼ばれる側、の意識の転換が、また一つ進んだ。
10年以上前に起こった、呼ぶ側、呼ばれる側の転換:第一次イベントドリブンブーム
これが
ユーティリティの利用
->
ユーザプログラム ---- OS、ライブラリ
こうなった。
イベント通知
<-
ユーザプログラム ---- OS、ライブラリ
今起こっている、呼ぶ側、呼ばれる側の転換:言うなれば「第二次イベントドリブンブーム」
これが
ユーティリティの利用
->
ユーザプログラムA ---- ユーザプログラムB(共通ライブラリ等)
こうなってきてる。
コールバック登録
->
ユーザプログラムA ---- ユーザプログラムB
<-
イベントor完了通知
要は、「基盤ライブラリ」対「アプリ」の考え方で、アプリは相変わらずのんべんだらりとあたまから実行するスタイルが残っていたのに対して、最近はいよいよ、アプリのつくりも、コールバックを登録するようなAPIスタイルが流行り始めている、と。
かつ、コールバック スパゲッティにしないために... 例えば M-V-VM パターンを推奨している人たちは、
- コマンドパターン
- オブザーバパターン
関数を呼ぶ、呼ばれるの関係が、ある程度複雑になるのは、（実行速度の頭打ちという）問題を解決するのに必要な複雑性である、と思う。
その次の話として、依存関係までを複雑なスパゲッティにしないために、M-V-VMパターンではオブザーバパターンを使っている、と理解している。
オブザーバパターン：
オブザーバとは、直訳すると監視者。
オブザーバ基底クラス サブジェクト基底クラス
================ -----------------
データ変更したよ通知() 通知先リスト
-----------------
+ワタシに連絡してね登録()
#変更したから連絡するよ()
△ △
| |
画面描画用のクラス 1画面分のデータを保持するクラス
---------------------
データA
データB
---------------------
データのGetメソッド()
これまで普通に作ってた3層アプリだと、
画面描画用のクラス <---- 業務ロジッククラス ----> データ管理のクラス
と、業務ロジッククラスがデータと画面を呼ぶ（相手が公開している処理を利用する）つくりになってた。だけどこれだと、業務ロジックが画面とデータの双方に依存するので、画面とデータの変更に、業務ロジックがヘコヘコ頭下げて追随する構造になる。
なので仕様変更の手順は
1)データを変更 2)画面を変更 3)業務ロジックを変更となる。
画面と業務ロジックの間の依存関係を逆転させるために、オブザーバパターンを使う。依存関係は
画面描画用のクラス ----> 業務ロジッククラス ----> データ管理のクラスとなり、仕様変更の手順が
1)データを変更 2)業務ロジックを変更 3)画面を変更と、1直線になる。
つまりソフトウェア的な工夫をすることで、コンポーネント間の強弱関係っていうか、依存関係が、すこしすっきりする。
オブザーバパターンで、かつ命令を適切に伝えるために、コマンドパターンが必要になる、と理解している。
コマンドパターン：
命令のデータ化。関数の名前で処理を分けるところからもう一歩冗長化して、データの先頭が命令であるようにする。
んで、よくあるのは、そのデータ構造をリンクリスト状に数珠繋ぎにできるようにして、マルチステートメントも可能にすることだけど、それはどっちかというと枝葉。
まだこの辺未整理。
ハドソンだかジェンキンスだか
ビルド管理システムの新しいやつが流行ってるらしい。
ハドソンという名前だったのが、商標だかの問題で ジェンキンスになったとか。
どっちも微妙な固有名だ...。
推理小説
うーん、柚木草平シリーズの新しいやつ出てたのか。
しかも娘さんが事件に巻き込まれとるらしい...
読みたいような、少し離れたいような。
ふと思ったが、柚木草平シリーズって、男はつらいよと構造が似てる気がする。もちろん全然違うんだけど、ちょっと似てる。
世間では「ぼくなつ」っていうとゲームのアレだと思うんだが、自分にとっては「ぼくなつ」は樋口有介氏。
やっぱちょっと本屋行ってこよう。