arclamp.jp アークランプ

先のエントリ、「POJOがしめすアプリケーションの形」に対して、クープルのjugyoさんから指摘をいただいた。（この人「頭固いな～」と思った。）

つまり「DIコンテナ」ってのはバーチャルマシンの一種なんだよ。

なんでみんなPOJOとかDIとかっていう難しい言葉で表現しようとするかな～。

うーん、ま、僕の表現が小難しいのはお許し願うとして、言い訳させてもらえれば、先のエントリは、DIコンテナを説明したかったのではなくて、POJOやDIで、何が出来るのかを説明したかったのだ。

現在、DIといえば、DIコンテナ（Spring Framework、Seasar2など）、いわゆる軽量コンテナである。DIコンテナでも、DIの効果は十分に証明されている。しかし、DIという概念そのものは、もっと応用性が高いのではないかと言われている。ま、DIコンテナ自身も、すべての可能性が洗い出されたわけでもないのだが。
そこで、先のエントリでは、「DIは、"現実的なMDA"という視点で求められているのではないか」という指摘をおこなった。つられて、POJOとか、AOPとか、O/Rマッピングとかがでてきている。

DIをメタファで理解してみる
ただ、DIについて分かりやすい説明が世の中にないのは事実である。なので、なんとかDIコンテナを説明してみたい。ただし、一言で表現しにくい。どういう言い方をしても、なにか不足してしまう。たぶん、ハードウェア的なメタファが使いにくいせいだと思う。

ちょっと考えたのが、レゴブロックで家を建てるというメタファだ。ブロックがビジネスロジックで、家がアプリケーションのメタファになる。分かりやすくするために、ブロックの色を機能だとする。なので、同じ色は2回出てこない。
ここで、DIコンテナの仕組みは、透明なブロックで家の構造を決めておき、色をあとから自由に注入できるようにするという感じだ。すべてのブロックには番号が振られているため、自分では、ブロックの番号と色の組み合わせ表だけを作ればよい。あとは、家をDIコンテナに渡せば、色付けをして返してくれる。
これにより、組立の共同作業に支障が出来にくいというメリットが得られる。これまでは、色づけしないと構造体につかってはいけなかった。しかし、色（機能）がない場合でも、とりあええず白（モック）にして作ってしまえばよい。これで、他人に迷惑をかけずにすむ。あとは、色（機能）が完成した時に、白（モック）を取り除き、その色（機能）を注入すればよい。
もちろん、色の入れ替え作業は、手元のブロックと色の組み合わせ表を変えるだけで、DIコンテナがよろしくやってくれる。

ま、正確なことを言えば、レゴのブロックは使ってしまうと、他に転用できないが、ソフトウェアの場合は、あくまでも参照なので転用が利く。あるいは、レゴの大きさや形（インターフェース）も様々である。他にも、実際にDIコンテナを利用する段階になると、微妙に感覚が異なってくるのだが、大きくは間違っていないと思う。

なので、jugyo さんがいうような、"「DIコンテナ」ってのはバーチャルマシンの一種"というのは、ちょっと端的過ぎるではないかと感じる。バーチャルマシンは、アプリケーションがどこでも動くことを保証するものだ。レゴで言えば、どんなでこぼこなところに作ろうと思っても、きれいに平行になるようにしてくれる土台がバーチャルマシンである。
つまり、バーチャルマシンはアプリケーションに利用される立場だが、DIコンテナはアプリケーションを組み立てる立場である。この、受動と能動の入れ替えが、大きく異なる点だ。
ただ、jugyoさんがいいたい事も良くわかっる。POJOが、POJO対応環境であれば、どこでも動く点、そして、存在が見えないという点で、バーチャルマシンが実現している世界と似ているのは確かだ。が、DIコンテナを、自分の責任で案件に使うのであれば、DIコンテナがバーチャルマシンという認識では、さすがにまずいと思う。

で、ここまで書いておいてなんだが、先のエントリは、DIの中身に興味がある人を対象にしていたということで勘弁していただきたい。ただ、どこかの時点で、DIの本質や価値について、わかりやすくまとめなくてはいけないと感じている。それを、お待ちいただければ幸いである。