DIへの賛否
1.DIへの賛否
10年ほど前、DIはソフトウェア産業の問題を解決する銀の弾丸として喧伝され、それを実現するDIフレームワークのspringやseasarが登場した。DIはとても流行し最終的にはEJB3.0に取り込まれるまでになった。ではDIとは一体何者なのだろうか。
ここではDIの正体とDIがソフトウェア産業にもたらした功罪について考察する。
1.1.DIとは何か
DIとはDependency Injectionの略で直訳すれば依存性注入となる。そしてその正体は「オブジェクトの組み合わせをコントロールする仕組み」である。
〈図1〉
…
図1はUserがCoffeeImplを生成しないという意味だ。
次のソースコードを見て欲しい。
〈コード1〉
class User{
private Coffee coffee=new CoffeeImpl(); //①
public void drink(){
coffee.drink(); //②
}
}
coffeeにnew CoffeeImpl()を設定しているが、もしこのCoffeeImplがDBに依存しているならUserクラスの開発環境にもDBMSをインストールしなければならない。またテストする度にCoffeeImplが利用するテーブルのデータも再ロードする必要がある。
他に値をセットするメソッドもない。となればこのクラスは②で確実にNullPointerExceptionが起きてしまう。つまりバグである。
〈コード2〉
<component class="User">
<property name="coffee">
CoffeeImpl
</property>
</component>
意味はこうだ。
「Userロード時、coffeeにCoffeeImplのインスタンスをセットする」
もし設定ファイルがなければ①は
private Coffee coffee=new CoffeeImpl();
としなければならない。これではCoffeeImplに依存してしまう。
例えばCoffeeImplの内部でDBアクセスしている場合
ロード出来ない環境では動作確認出来ない。スタブとしてCoffeeImpl4TestをCoffeeImplの代わりに使いたい時にもUserクラスを修正し、動作確認が終わればまた元に戻さなければならない。
所がそのためには
上の設定ファイルの例ではCoffeeImplを設定しているが、
これによりUserクラスはCoffeeImplクラスへの「依存性」をソースコードに記述しないですむ。
設定ファイルにより「注入」できるため様々なメリットがあるのである。
