フレームワークって何?　という質問をされて困ったことがある。 今では定番の技法の一つだが、 特に最近、フレームワークはちょっと流行っているようだ。

Java の世界には Struts という大御所がいるのだが、 最近(という程でもないのだが)は JSF とか Spring とか流行しだすと、 「JSF と struts は一緒に使えますか」みたいな質問が FAQ になっていたりする。 最近のフレームワークは、 フレームワーク全体がパーツの組み合わせのような構造になっていて、 一部をフレームワーク外の処理に置き換えて使えたりするので、 実際、いろいろ合わせ技もあるようで、 その種の再利用性は向上しているように見える。

※ 組み合わせて使うのは意外と簡単だ。 最大の問題は、そのためには両方の知識が必要だということである。

§

昔のコンピュータは、 今のように資源が豊富でなかったから、 少ない資源を有効利用する技術は特に重視された。 私がアルバイトでゲームのプログラムを書いていた頃、 ゲームカートリッジの容量は8KB しかなかったし、 開発に使うパソコンのメモリは64KB だった。 限られた数の命令しか書けないという厳しい制約条件のもとで、 できるだけ多くの処理をこなせ、 というのがプログラマーに与えられた使命だったのである。 ある程度までなら、この問題は割と簡単に解決できる。 共通の処理をサブルーチン化してくくりだせばいいのだ。

さて、プログラムを再利用するという課題は、 今でも重要な課題の一つである。 メモリやディスクをふんだんに使えるようになると、 プログラムは巨大化するようになった。 そして、 保守性とか人的資源の問題が無視できなくなってくる。 同種の処理があちこちに分散していると、 修正が必要になったときに、 何箇所も同じような修正を行わなければならない。 その結果、テストは大変になるし、修正もれが発生するし、バグが生まれる。 つまり、保守性が低下するのである。

人件費はどうだ。 もちろん、バグを修正するにも人件費がかかる。 それ以前に、 同じような処理を再開発すること自体が無駄に他ならない。 他にある処理をコピーするのは再開発とは言わないかもしれないが、 本当に同じような処理を各自が作るというようなことは、実際あるものだ。 これが開発者のスキルアップになるという考え方は否定しないが、 そうだとしても、 既にあるコードを一度読んでから作った方が効率的だし、勉強にもなる。

§

古い言語の寿命は意外と長い。 C言語はもちろんその中の一つだし、 Perl だって健在だ。 このような言語が生き残る条件の一つが、 既存の資産である。

perl には、 少し変更すれば要求を満たせるようなスクリプトが多数公開されている。 しかも、膨大な数のライブラリ・モジュールが存在するし、 少し複雑なことをしたいときに、 これらのモジュールを組み合わせることで、 コーディング量を減らすことができる。 これは結構大きな生き残り要因になるのだ。

昔、Java には「重い」とか、「言語仕様がいまいちだ」とか、 いろいろ批判もあったし、今もある。 消え行くのではないかという予想をする人もいたが、 健在だし、むしろ使われる場は増えつつある。 これも、言語仕様というよりは、 Sun のオープンソース戦略の影響もあるだろうが、 豊富なライブラリとか、 コードごと公開された無数のクラスが重要な役割を果たしているのだ。

Java ちょっとした処理をしたいと思ったときの、 よくある手順はこんな感じだ。 まず、それを誰かが既にやっていないかを調べる。 あれば、それを使えばいい。 なかったら作る。

※ たいていあるのだ。

特に Jakarta Project のようなオープンソース系のプロジェクトには、 多くの人が欲しいと思っている処理が、豊富に揃っている。 あなたが欲しいと思っている機能があれば、 他にも欲しいと思っている人は大勢いるし、 誰か作っている確率は高い。 モジュールとか共通ライブラリという発想は自然と生まれてくるもので、 その延長線上にフレームワークがある。

§

JSF (Java Server Faces) に関する和書が、 少しずつだが書店に並ぶようになってきた。 これは第二世代のMVCフレームワークと言われている。 批判も結構多いようだが、 JSF が出てくるまでに、 さまざまな紆余曲折とかドラマがあり、 その結果の公式仕様が JSF なわけで、 そう考えると、挑戦的というよりも、 今までの技術のまとめなおし系、という感じがしないでもない。 Struts を使ったサイトやアプリケーションは結構あるのだが、 今後、JSF を使ったサイトがどの程度出てくるか期待したい。

MVC モデルにも批判がある。 モデル、ビュー、コントローラーを分離するというのが基本コンセプトだが、 そんなの分離できるのか、という懐疑的な人とか、 分離するために余計なインターフェースを増やして、 実は分離していないという事実を隠しているのではないかとか、 そういう意見もあったりするが、 とりあえず MVC というからには、 View だけを別チームで開発というようなことはよくあるだろう。 この View の開発チームが画面を設計するときに、 面白い現象が起こる。

※ そもそも、それは分離できるものなのか、 という批判が意外と説得力があるような気がする。

ブラウザが、 page1.jsf というページを表示しているところを考える。 この画面の何かボタンを押すと何が起こるのか。 画面表示だけに注目してごく簡単に紹介すると、 まず、リクエストを受け取ったサーバーは、 page1.jsf に対応する「ビュー」というものを復元する。 その後、アレコレと処理して、 画面遷移のルールを適用した結果、 HTML のデータを生成して、 表示画面としてブラウザに戻す。

「JSFのライフサイクル」の詳細は、 JSF の仕様書に書かれているし、 JSF 関連書籍には必ず出てくる話題なので、 そちらを見て欲しい。 仕様書の説明が元になっているから、どの本を見ても中身は大差ない。

さて、画面遷移のルールは、 faces-config.xml というファイルに書くことになっている。 page1.jsf を処理した結果、 ok が返された場合には ok.jsf に遷移し、 ng が返された場合には ng.jsf という画面に遷移する、というルールは List 1 のように書く。

---- List 1 faces-config.xml の一部 ----

  <navigation-rule>
    <from-view-id>/faces/page1.jsp</from-view-id>
    <navigation-case>
      <from-outcome>ok</from-outcome>
      <to-view-id>/faces/ok.jsp</to-view-id>
    </navigation-case>
    <navigation-case>
      <from-outcome>ng</from-outcome>
      <to-view-id>/faces/ng.jsp</to-view-id>
    </navigation-case>
  </navigation-rule>

---- List 1 end ----

この画面遷移のルールは、 MVC のどの担当者が書くのか、 という問題もありそうだが、 このルールを書く人の感覚としては、 ok に対しては ok.jsp を元にしたページを画面に表示する、 という発想を持っているはずだ。 ただ、とりあえずここで気になるのは、 ブラウザを見ると、 表示している URL は、 ok.jsp でも ok.jsf でもなくて、 page1.jsf なのである。 これはどういうことなのか?

ブラウザから考えてみよう。 ブラウザは一体何を表示するようにサーバーにリクエストしたか。 例えば、http://www.phinloda.com/hoge.cgi という CGI のページにアクセスしたら、 その都度何かページを生成してブラウザに返すようなサーバーを想像して欲しい。 もちろん、ユーザーは 「http://www.phinloda.com/hoge.cgi を表示した」 と思うだろう。 これは別に何のマジックもない、 当たり前の感覚だ。

では、JSF の場合は一体何が起きているのか? page1.jsf が表示しているボタンをクリックするというのは、 form のボタンを押すのと、同じことだ。 ソースを見ると List 2 のようになっている。

---- List 2 page1.jsf のソース表示 ----

  <form id="page1" name="page1" method="post"
   action="/Bookmark/faces/page1.jsf"
   enctype="application/x-www-form-urlencoded">
     …以下略…

---- List 2 end ----

ブラウザから見れば、 サーバーの中で何が起きているのかは知ったことではない。 ただ単に page1.jsf を action として呼び出し、 戻ってきたページを表示しただけだ。 だから、 URL の表示欄には、 page1.jsf と表示するしかない。

ところが、画面や画面遷移を設計した人の発想で考えてみると、 ブラウザが表示しているページの原型は、 page1.jsp ではなく、 ok.jsp や、 ng.jsp なのだ。 慣れてしまえば気にならないかもしれないが、 違和感がどうしてもつきまとう。

§

その昔、MULTICS というお化けのような OS を作ろうとして挫折した人たちがいた。 その教訓は、細かい単位で作って組み合わせた方がいい、ということだ。 そして生まれたのが　UNIX である。 独立して動作可能な小さな機能を作っておいて、 連携して全体の処理を行う、 というのはプログラミングとしては伝統芸能みたいなもので、 その発想自体は使い古された手法の一つなのだ。

独立した個々の機能が組み合わさって大きな処理を作る、 というシステムは、例えば地球というのがそうである。 プログラミングというモデルが、 地球のシステムを模倣するような道に向かっているのだとすれば、 やはり摂理のようなものがあるのかもしれない。

フレームワークが多種多様になってくると、 組み合わせるということ自体が面倒になってくるから、 そのうち、 フレームワークを選択利用するためのフレームワークが出てくるだろうか。