先のエントリ、「POJOがしめすアプリケーションの形」に対して、クープルのjugyoさんから指摘をいただいた。（この人「頭固いな～」と思った。） つまり「DIコンテナ」ってのはバーチャルマシンの一種なんだよ。 なんでみんなPOJOとかDIとかっていう難しい言葉で表現しようとするかな～。 うーん、ま、僕の表現が小難しいのはお許し願うとして、言い訳させてもらえれば、先のエントリは、DIコンテナを説明したかったのではなくて、POJOやDIで、何が出来るのかを説明したかったのだ。 現在、DIといえば、DIコンテナ（Spring Framework、Seasar2など）、いわゆる軽量コンテナである。DIコンテナでも、DIの効果は十分に証明されている。しかし、DIという概念そのものは、もっと応用性が高いのではないかと言われている。ま、DIコンテナ自身も、すべての可能性が洗い出されたわけでもないのだが

Javaの世界では、POJOというものが流行している。Plan Old Java Objectの略で、Martin Fowler氏らの造語だ。シンプルで、依存性をなくしたオブジェクトのことをさす。しかし、このPOJOというものをどう捉えるべきか、まだまだはっきりしていないのではないかと感じる。ここでも、僕なりの説明を試みるわけだが、正解といえるかは分からない。ただ、方向性としては間違っていないと思っている。 POJOとは まず、POJOを、もう少し詳しく定義するなら、「自分がするべきことに対して最低限しか知らないオブジェクト」、さらに「実行環境やフレームワークのことは一切知らないオブジェクト」といえるのではないか。たとえば、ビジネスロジックを担当するPOJOであれば、自分のするべきこと、まさにロジックと、そのロジックに必要な他オブジェクトのインターフェース（まさに、interface）し