Strutsの次にくるもの
最近の仕事の中で，何らかのシステムを作るときには，問答無用でWebアプリケーション，そしてStruts採用，という感じがほとんどを占めている。これは，多くのSIerがきっとそうだと思う。とりあえずStrutsを選んでおけば安心だ，と言った感じだろうか。開発者も集めやすいし，事例や自分自身の経験もたっぷりだ。中，大規模案件でも，それに対応できるだけの問題対処パターンは豊富だし，別段ネットで調べなくとも，だいたい自分の経験値の中で解決できている。 しかし，そろそろ次のステップに行かなければならないな，と最近になって強烈に思うようになった。J2EEのNext Stepは，Java ServletやJSPといった，いかにもWebアプリケーションです！というAPIではなくなる傾向がある。特に，EoDというキーワードに基づいて，今後必要とされる知識は，ちょっと違ってきているのではないだろうか。極端な言い方をすれば，今まで多くの技術者が必死に得てきたWebアプリケーション特有の知識が，一切役に立たないものになってしまう気がする。 GUIアプリケーションの構築は，基本的にイベント指向やコンポーネント指向が素直に適用可能な分野である。さらに，GUIアプリケーションのクライアントとなるAWTやSwingを使ったアプリケーションは，個別にオブジェクトをステートフルに扱うことができるため，オブジェクト指向を素直に実践することができる。その証拠に，GoFのデザインパターンは，GUIアプリケーションの構築に対して最大の威力を発揮するものである。 GUIアプリケーションの次に登場したWebアプリケーションは，HTTPというその特異な性質に合わせて，オブジェクト指向に基づいた構築技法が通用しない世界に変えてしまった。HTTPセッションがあるとは言え，コードのほとんどは「単なる関数集」といっても言い過ぎではないだろう。Webアプリケーションの構築のために数多く作られるクラス群のほとんどは，ステートレスな使われ方しかしない。つまり，インスタンスフィールドが定義されないものがほとんどなはずだ。インスタンスフィールドなんぞ定義したら，「複数のスレッドが同時に来たらどうするんだボケ！」と9割方アーキテクトに説教されるだろう。 Webアプリケーションの普及によって，オブジェクト指向とはとても言えない関数集合的アーキテクチャが氾濫してしまったため，最近のJavaの開発現場は「コーディング命」になってしまった。Microsoftな世界から来た技術者は，Javaの開発現場を見て，相当なダメダメ感を覚えることは確実。なんでこんなにコード書かなくちゃいけないの！？という怒りを感じるだろう。 しかし，DIやSOA，Ajaxなどの「次の世代」の登場により，そろそろJavaの開発現場も「新たな変化」が起きるべきだと思っている。コードエディタでドカドカとコードを記述するのではなく，まともなオブジェクト指向，つまりイベント指向やコンポーネント指向という誰もが認める（であろう）開発方式をこの手に取り戻す必要がある。WebアプリケーションのGUIアプリケーション化だ（MSの世界では既に実現されているところが悔しい）。 Web2.0の登場によって，この流れはソフトウェア業界の有名人には認知され始めていると思って間違いない。そして，何も考えずStrutsを採用してしまうのではなく，これからはDIはもちろん，JSFによるAjaxコンポーネントやESB，POHPソリューションを中心に，今までのWebアプリケーションの作り方や画面設計そのものに身近から変革の波を作っていこうと思う。
