みなさんこんにちは、masa です。今日は Spring Framework などでお馴染みの依存性注入（DI）コンテナについて解説してみたいと思います。今回の記事は、オブジェクト指向でプログラムを書いている方向けとなります。

依存性注入 = Dependency Injection とはなんぞや？という方のためになるべく簡単にその解説を書いてみたいと思います。

 

依存性注入（DI）ってむずかしい言葉いったいなんですか？

継続的インテグレーション（CI）もそうですが、日本語に直訳してしまうと、とてつもなくわかりづらいワードになってしまうものがあります。この DI もそうです。

私も初めて Spring を触ったときはこのワードに惑わされた感がありました。だからブログにネタを書くときは絶対に人にわかりやすいように書きたいと思ったものです。依存性注入というのをわかりやすくいうと

 

クラス同士を疎結合にして、実データは外部へ出しちゃいましょう

 

ということです。いったいなんのために？

 

クラスの単体テストをしやすくするためです

 

下の図のようにクラスAの中でクラスBを呼び出している場合、クラスAがクラスBに依存しているといいます。この場合、クラスAができあがって単体テストを行いたくても、クラスBが出来ていないとそれができません。

 

では DIコンテナを使った場合はどうなるのでしょうか。下の図を見てみてください。

クラスAはインターフェースXを呼び出しているだけなので、クラスBが出来ていなくても単体テストができます。そう、インターフェースXがモックの代わりになり、実データ（＝リテラル）をクラスBに外出ししているのです。

昔の Spring では実データを XML ファイルに書いていましたが、”脱XML”のトレンドからすれば今は上記のようにインターフェースをかませる方法がスマートと言えるでしょう。もちろん現行の Spring でも XML で設定することは可能です。

単体テストがかんたんにできる以外にもメリットはあります。上図の中で、インターフェースXが検索するパッケージ場所を設定ファイル（これはXML）で管理するのですが、その検索するパッケージを書き換えれば、インターフェースXのデータを本番用の”クラスC”に一瞬で切り替えることが可能です。

ちなみにこの DI機能は、JUnit でも使えるので、テスト駆動開発の場合でも導入できると思います。

 

いかがでしたか？今日は理解の難しい DI コンテナについて取り上げてみました。DI のデメリットとしてインターフェース数が増えることや、そもそも現場の学習コストの問題もあります。使えば必ずしも品質や納期が改善されるわけではないのでメリット・デメリットを天秤にかけて導入を検討してみてください。