Wicket好きはコーティング好き？
Wicketの特徴として「Javaで何でも書くことにより，Javaプログラマが生き返る」ということがある。これは確かにそのとおり。特にJDK1.1の頃からJavaに携わっている開発者にとって，Wicketでアプリケーションをコーディングした結果は，あの頃のGUIアプリケーションに非常に近い。近年の多くのWebアプリケーションに比べて，自分の時代が戻ってきた！という感覚を開発者は持つだろう（Webアプリしか知らない人には体感できないかも）。 ただしこれは「アプリケーションの記述言語としてJavaを使う割合とそれについて得られるメリット」がポイントなんであって，Wicketを採用する人々が「コーディングが苦にならない」「コーディング大好き！」っていうことには直結しない。 現に，僕はコーディング量は減れば減るほど嬉しい。 Javaの登場以来，オブジェクト指向言語を利用することは当たり前となった。そして，デザインパターンなど多くの設計指針が一般に広まった。Webアプリケーションが登場する前，多くの開発者はGoFのデザインパターンなどの恩恵を受けていたことと思う。そして，MVCなどのパターンも無理なく自然に採用していただろうし，ロジックのコンポーネント化もカプセル化をうまく使って行えていたはずだ。その中で，継承や委譲を使って，コーディング量の削減や戦略の外出しを実現していたことと思う。 Webアプリケーションは，HTTPの特徴と処理の特性に依存して，関数型の開発手法となってしまった。つまり，サーバ上で状態を持つオブジェクトを利用することが難しくなってしまった。MVCについても，そのまま適用することはできず，MVC1やMVC2といったカスタマイズを施すことになってしまった。さらに，世間のEoDが「Javaでのコーディング量の削減＝XMLによる設定ファイルの記述」という方向に流れてしまったため，JSPの普及も合わさって，複雑さが増してしまった。 オブジェクト指向言語は，GUIのソフトウェアの構築を見据えて発展してきた歴史がある。GoFのデザインパターンについても同様だ。つまり，カプセル化，継承，委譲，多態性など，オブジェクト指向言語を最大限生かすことができるターゲットは，GUIアプリケーションであると言える。XMLやJSP，スクリプト言語などを持ち込むことなく，オブジェクト指向をうまく使うことに主眼を置くことが，GUIアプリケーション構築には最適解だと思う。 Wicketは，Webアプリケーションについても，オブジェクト指向言語を使うことによるメリットを最大限受けられるように良く考えられている。つまり，GUIアプリケーションを構築するときと同じようなAPIセットを使ってWebアプリケーションをコーディングできるようにしてあるのだ。オブジェクト指向というJavaの原点を生かせるフレームワークこそが，Wicketである。 そのためWicketは，オブジェクト指向への深い理解と高い設計理論が求められる。しかも，GUIアプリケーションを構築するときと同じレベルの「面倒な」コーディングが求められる。GUIアプリケーションは，特にUIに関するコーディングについて，ボタンやテキストフィールドなどをコンポジットパターンで組み合わせていくコーディングがどうしても開発者の負担として付きまとう。従来では，IDEによるビジュアルなデザイナを使ってUIを構築したり，基本となるUIコンポーネントのクラスを拡張して，よりドメイン依存なコンポーネントを作ってそれを組み合わせることで，プログラマの負担を軽減するアプローチを取ってきた。 それと同じ工夫が，広く普及したWebアプリケーションフレームワークに比べて，多く求められるのがWicketだ。 こういう風に書くと，デメリットなように感じるかも知れない。しかし，GoFなどを見ればわかるとおり，GUIアプリケーションの構築を代表的な対象とする，オブジェクト指向言語を利用する際のクラス設計論について，既に我々は数多くのベストプラクティスを持っている。それらを（MVC2のように変にカスタマイズすることなく）素直に適用することができるのが，Wicketなのである。そして，Wicketを採用する人々は，Java登場以来ずっと蓄積されてきたオブジェクト指向的設計論を素直に使えることについて魅力を感じているからこそ，積極的に採用しているのだと思う。 Wicketを使えば，XMLファイルやその他設定ファイルを強制されることなく，Viewのための非常に複雑な機構を強制されることなく，Javaコードのみで業務を満たす最小のコードセットを作れる（もちろん，これの実現のために，Wicket自身は非常に複雑なコードとなっていて，しかもオブジェクト指向を生かすために積極的にHttpSessionを利用するため，サーバリソースを多く使用する）。そして，Javaのみでほぼ完結するため，コードを削減するための努力について，さまざまなアプローチを取ることができる。 リッチな共通部品を作ってもいいし。 ユーティリティクラスを作ってもいいだろうし。 アノテーションを提供して親クラスでそれを解釈するようにしてもいいだろうし。 そこにテンプレートパターンを適用してもいいし。 Panelによるコンポジットパターンで汎用化を進めてもいいだろうし。。。 そこにはJavaの開拓者が生み出してきたどのような知恵も持ち込むことが可能なのだ。 Wicketは，Javaプログラマにとって，自己主張が少なく，わがままでもなく，とても素直なフレームワークと言えるのではないだろうか。XML地獄に陥ることなく，コード量の削減をJava言語の特性を生かして素直に実践することができそうだね，というようにWicketを見て欲しいと僕は思う。
