Javaの世界では、POJOというものが流行している。Plan Old Java Objectの略で、Martin Fowler氏らの造語だ。シンプルで、依存性をなくしたオブジェクトのことをさす。しかし、このPOJOというものをどう捉えるべきか、まだまだはっきりしていないのではないかと感じる。ここでも、僕なりの説明を試みるわけだが、正解といえるかは分からない。ただ、方向性としては間違っていないと思っている。
POJOとは
まず、POJOを、もう少し詳しく定義するなら、「自分がするべきことに対して最低限しか知らないオブジェクト」、さらに「実行環境やフレームワークのことは一切知らないオブジェクト」といえるのではないか。たとえば、ビジネスロジックを担当するPOJOであれば、自分のするべきこと、まさにロジックと、そのロジックに必要な他オブジェクトのインターフェース（まさに、interface）しか知らない。
しかし、POJOだけでアプリケーションは構築できない。なぜなら、POJO自身は、アプリケーション全体の中で、いつ動くべきか、どう動くべきかをまったく知らないからだ。まわりが、お世話してあげなければ、なにもできない。
DIコンテナ
そこで登場するのが、DIコンテナ（Dependency Injection:依存性の注入。軽量コンテナ、IoCコンテナ）だ（参照：Java開発を変える最新の設計思想「Dependency Injection（DI）」とは）。
前述の通りPOJOは、最低限の事しか知らない。つまり、依存性を極力排除している。DIコンテナの役割は、そのPOJOに対して、依存性を注入することにある。ビジネスロジックのPOJOでは、内部で使用する他クラスのインターフェースを対象にロジックを書いておくが、DIコンテナが、そのインターフェースに実装を注入してあげるのだ。
そして、DIコンテナが、どのPOJOに、どんな実装を注入すべきかは、設定ファイルによって決定される。つまり、設定を切り替えれば、実装を切り替え、アプリケーションの動きを変えることが出来るわけだ。
現在は、これがテストに有効だとされている。利用したいインターフェースの実装が開発中であっても、自分でモックオブジェクトと呼ばれるダミーオブジェクトを作成し、それを設定しておけばよい。そうすれば、自分の世界だけでテストが行える。
なお、Fowler氏は、こうしたDIの考えを、「設定を利用から分離する」（原文：separating configuration from use）と表現している。
ちなみに、DIコンテナが扱えるのは、POJOだけではない。Spring Framework状で、StrutsのActionを対象にするという仕組みも存在する。
アスペクト指向・フレームワーク
さて、DIコンテナとセットで語られることの多いAOP（アスペクト指向プログラミング）も、同じようにお世話係のフレームワークだ。もっとも有名なAOPの利用方法としてログの出力がある。ログを出力すべきPOJOを指定することで、POJO自身にログを出力するつもりがなくても、ログがでてくるようになる。ある意味、依存性の強制注入とも表現できる気がする。
なお、アスペクト（日本語では、見地）というのは、アプリケーションをある視点からみた切り口のことで、アプリケーションの中で横断的に利用されるような機能を外部化してしまうというものだ。
O/Rマッピング・フレームワーク
もう１つ、POJOに対して、データを注入/取出するのがO/Rマッピング・フレームワークだといえる。O/Rマッピングは、オブジェクトの永続化を受け持つ。その際に、リレーショナルデータベースの項目と、オブジェクトの属性のマッピング設定を参照しながら、実際のデータを永続化したり、復元したりする。この際のPOJOは、Transfer Objectなので、ただのGetter/SetterだけをもつJavaBeansに過ぎない。（データと振る舞いの分離は、POJOの本質議論とは別のような気がするので、ここでは触れない）
なお、EJBのような、古くからのO/Rマッピングだと、データを持つ部分がPOJOにならずに、特殊な継承を要求されてしまう（javax.ejb.EntityBean）。つまり、POJOではない。しかし、最近ではPOJOに対応したO/Rマッピング・フレームワークも存在する。そして、そういった動きを受けて、EJB3.0やJDO2.0では、POJOを利用した永続化処理に移行すると発表されている。
POJOがしめすアプリケーションの形
ここまで、DIコンテナ、アスペクト指向・フレームワーク、O/Rマッピング・フレームワークと、３つのフレームワークを見てきた。どれも、POJOを対象に、POJOがアプリケーションで、どう動くべきかをお世話していたといえる。Fowler氏の「設定を利用から分離する」という言葉は、POJOを扱うすべてのフレームワークに共通する概念だといえるだろう。
これは、設定ファイルという"糸"を使って、ビジネスロジックという"布切れ"を、縫い合わせるようにして、アプリケーションを組み上げる（assemble）ための手法といえる。
ある意味、現実的なMDAともいえる。UMLのようなモデリング言語は、オブジェクトの形や振る舞いをしめした、いわば設定だ。従来のトップダウン的なMDAでは、UMLからのコード生成で、動くものが出来ないといわれている。それは、言語を超えて共通の動作を行うという理想論に対して、ビジネスロジックをモデル化する手法が、実際にJavaのコードを書くことに比べて、あまりにも貧弱な機能しか持たないからだ。しかし、このPOJOを利用する手法では、コードでやるべきところはコード、設定に出来るところは設定というボトムアップアプローチによって、現実的なMDAができあがっている。
僕は、このような、POJOを組み上げるという手法が、新しいアプリケーションの形だと思っている。ただ、いくつかの課題があることも事実だ。
EJBが目指したコンポーネント指向には、EJBコンテナへの依存性という問題があった。これは回避されたが、粒度の問題はどうするのか。
また、EAIからBPMの流れであるBPELのように、ロジックそのものは、どこまで設定ファイル化すべきなのか。
さらに、ユーザーインターフェースへの依存性をどう解決すべきなのか。
そして、この手法の延長には、SOAが見えるわけだが、どう関係してくるのか。
これらは、そもそも、解決すべきなのかもわかっていない。この方向性でアプリケーションを作りながら、検討が続くことだろう。
さて、すっかり、更新が滞ってしまった。案件が複数同時に進んでいるので、毎日わたわたしてしまっている。いかんなぁ。
