ひがやすを技術ブログ

電通国際情報サービスのプログラマ

DIって本当に必要? その3

http://d.hatena.ne.jp/higayasuo/20070417#1176775996の続き。
それでは、DIContainerが提供する機能でもっとも重要な機能って何でしょうか。
AOPだと思います。
それなら、「AOP専用フレームワークを使えばよいじゃん」という声が聞こえてきそうですが、現実的に普及しているAOP専用フレームワークがない(ライブラリとしてはJavassist, cglib, asmなどは普及していますが)ので、AOPを使いたいときは、DIContainerを使うというのが現実的な選択肢ではないでしょうか。
AOPは、トランザクション、ログ、セキュリティ、例外の一元管理など非常に有用で、AOP抜きの開発は考えられないほどです。
AOPを使わなくても同様のことはできますが、その分工数がかさみます。
AOPは、システムに精通したエンジニアが一元設定しておけば、普通の開発者はその存在を気にする必要はないので、失敗しにくい安定した技術だと思います。
まとめると、DIはテストをしやすくするために重要ですが、別にわざわざDIContainerを使わなくてもsetterメソッドさえ用意しておけば利用できます。DIContainerを使うメリットは、AOPインスタンス管理にあるのではないかと思います。言い方を変えれば、DIは行わず、AOPインスタンス管理に特化したフレームワークがあっても十分に有用なのではないでしょうか。
はっきりいって今の開発を複雑にしているのは、「いきすぎたPOJO信仰」ではないかと思っています。今回の一連のエントリーは自分自身への反省も踏まえて書いています。
もともとのPOJOの目的は、

  1. 特定の環境に依存しないのでテストしやすい。
  2. 特定のフレームワークのことを覚えなくても開発できる(普通のJavaだから)。

といったことがあったと思います。曲者は、二つ目ですね。たしかにPOJOを書く分には余分な知識は要りませんが、DIContainerを使ってコンポーネントを組み合わせるところが難しいところだと思います。
結局、DIContainerの設定ファイルを書くのは敷居の高い行為です。Seasar2のように設定ファイルをなくせば、設定ファイルを書くという行為は必要なくなりますが、自動で処理されて不安という声はあるでしょう。
IoC(自分で呼び出さずに外部から自分が呼び出される)というのは、自分で処理がコントロールできないので、もともと直感的なものではないのです。IoCがDIを敷居の高い技術にした原因だと私は分析しています。
それでは、どうすればよいのでしょうか。続きは次のエントリーで。