シーサーと言っても沖縄の妖怪ではなく、フリーソフトウェアの開発プロジェクトThe Seasar Projectで開発中のDI (Dependency Injection) とAOP (Aspect Oriented Programming) をサポートしたコンテナSeasar2のこと。要はプログラムを作るための基盤なんだけど、以下、専門外の方ごめんなさいの内容。
JavaWorldで国産のアプリケーションコンテナということで紹介記事があったので、ちょっと興味を持ったので試してみた。こういうコンテナというとSpring Frameworkが有名だけど、結構前に簡単なプログラムでSpring Frameworkを試してみたことがあって、それをSeasar2に移植してみたらどうか、ということでやってみた。結論から言うと、たいして苦労することなくできた。後発の強みだと思うが、コンポーネント間の依存関係を定義する柔軟性ではSeasar2の方が上という印象。
今回試したサンプルアプリケーションは、名前を入力すると"Hello, <名前>"と答える単純なスタンドアロンのGUIアプリ。
プログラムはコンテナからJFrameを取り出して表示するMain.java、テキストフィールドに入力された名前を表示する処理を書いたHelloOperation.java、プログラムを終了する処理を書いたExitOperation.javaのみ。GUIの組み立てとイベントと処理の関連付けは、すべてSeasar2の定義ファイルHelloWorld.diconに記述した。
Spring Frameworkからの移植にかかった作業のほとんどは、定義ファイルの記述の翻訳作業。Main.javaはSpring FrameworkのコンテナからJFrameを取得するところをSeasar2から取得するように変えただけだし、HelloOperation.javaとExitOperation.javaはSpring Frameworkとの依存関係をなくしただけ。この2つは、本来コンテナに依存してはいけないはずなのだけど、Spring FrameworkだとAWTのイベントと処理の関連付け(イベントリスナの登録)をそのまま定義ファイルに記述できないので、プロパティ設定でできるように手を加えていた。
ちょっと思ったのだけど、この定義ファイルって、よくあるGUIビルダでビジュアルに設定する内容と似てる。使う部品を指定して、プロパティを設定して、イベント処理との関連付けを指定する。JBuilderだとこういった設定からソースを自動生成してくれるのだけど、この定義ファイルを自動生成するというツールもありうる。よく考えると、GUIビルダで設定するものって、GUI部品やイベント処理といったコンポーネント間の依存関係だから、Dependency Injectionのために記述する定義ファイルに記述されるコンポーネント間の依存関係と似るのは当然か。
