= DIする理由 =

※以下に示す数値には何の根拠も無い。独断と偏見である。

数年前からSpring、PicoContainer等のフレームワークが出現し、大きなプロジェクトでは盛んに用いられているようなのだが、そもそも何故DIするのか？その辺から考えてみる。

理由の99%は、ユニットテストを簡単にするためである。

世間では、それに加えて再利用のため等と言ってはいるが、こじつけに過ぎない。再利用されるとしても、同じプロジェクトや同じ会社内のことであろう。例えば、DIの設定が必要なプロジェクトがオープンソースとして広く利用されている例は聞かない。一つにはDIのやり方が標準化されていないという理由があると思われるが、しかしそんなことよりもテスト容易性の方がとりわけ重要なのである。

また、DIをやっただけで再利用可能になるわけではない。再利用可能とするためには、DIよりもむしろ、きれいなAPI設計や拡張可能性の方が重要になってくる。もちろんそのライブラリなりフレームワークなりが有用なものでなくてはいけない。DIが役に立つとしても残りの数％でしかない。

これに対し、DIすれば、どんなひどい設計のなおかつ他人には一切役に立たないコードであっても、確実にユニットテストを楽にすることができる。

では、ユニットテストは何のために行うのだろうか？

３０%は、管理者の自己満足と顧客に対して「テストを完全にやりました」と証明するためのものである。これはとても重要なものであることは言うまでも無いが、もちろん最優先事項ではない。

あとの70%は、仕様は変更されるという理由である。どこかの本に書いてあったが、開発者にとって不可避なものとは以下の三つだそうだ。

 * 死
 * 税金
 * 仕様変更

仕様変更はありとあらゆる理由で行われる。仕様が固定することを諦めた人達のことを世間ではアジャイルと呼ぶ。それならば、すべての開発者はアジャイルでなければならないはずなのだが、なぜかそれを拒否する人々、あるいはいまだにそのことに気がつかない人々もいるようだ。

ともあれ、仕様は変更される宿命なので、そのたびに「これまで動いていたのに、動かなくなってしまったコード」が出現するのである。ユニットテストとは主にはこれを救うためのものである。管理者の自己満足と顧客に対するアピールは副次的なものに過ぎない。

= DIの困難性と他の方法 =

しかし、DIを利用するのは最初は難しい、というより難しかった。理由は、

 * 以前のSpringに代表される、XMLを記述してのワイヤリングという面倒な作業をしなければならなかった。
 * そもそもDIの概念自体が、それ以前からの開発者にとってはとっつきにくい。というより、ぱっと見で訳がわからない。
 * 前述したようなDIするべき理由がわからない。ユニットテストなど不要と思っているからである。つまり必然性がない。

ということで、DIしないのである。特に小規模なプロジェクト（1～3人程度）では、そんなものを勉強するための金も出ないし、時間も無いのでDIしないのである。

しかし、ユニットテストのための方策は何もDIだけではない。主な方法論としてはファクトリとサービスロケータというものがある。
ユニットテストが困難な理由は、テスト対象を他から取り出し、それだけをテストするということができないからである。これを解消するための方法論はDIのみではない。