DIのアンチパターン

ってそろそろ語られててもおかしくないですね。インターフェース不要論って、実はDI不要論の事なんじゃないのかと思うんですよ。「DI」って、とてもいい概念なんですが、使い始めるとDIコンテナを対象にこれでもか!とPOJOのプロパティ設定を書き始めた事がありました。最近はそんな過去のおいらに、「おいちょと待てよ」と声をかけたくなってきました。
要するに言いたいのは、DIコンテナを過度に使いすぎるな、という事と、プログラムの再利用にDIコンテナを利用すると面倒なことがあるよ、という事。
DIのDは依存性のDなんですよね。何かに依存するようなDを設定として切り出す訳です。それってなんよ?と考えてみたところ、「環境」のことだったりするのではないかと思うんです。例えばテスト環境と、開発用のAP環境と、プログラム結合用のAP環境で接続するDBが違う、そんな場合にDIは有効です。アプリケーションが永続化処理として依存するDBを後から注入するわけですから。*1
その他にテスト時と実行環境での処理を変えるような実装があれば、その部分にDIを適用します。でもそういう箇所はそれほど多くないと思うんです。
よくプログラムを再利用するためにDIコンテナを用いる事があるとおもうんです。けれど、それって、DIコンテナを使わないとできないことかと言われれば、決してそうじゃない事が多いでしょう?そういう時はソースコードに書く事をお勧めします。DIコンテナを使ってBeanを注入するという事は、なんらかの形で、ソースコードに書く代替手段を使っています。たとえばXMLを使って注入するBeanの定義を書いているわけです。そういうことって忘れて作業しちゃいますよね。すると後で自分の首を絞めることがあります。
例えば実行時の状態によって、注入するBeanを切り替えるとか。いや、DIコンテナでできないよね?って言いたいんじゃなくて、プログラムで書いておいたほうがきっと楽できるよという事を言いたいんです。DIコンテナの設定ファイルに書ける設定は、かなりの部分が静的に変わらない部分だけじゃないでしょうか。想定されていたとしても、大抵はソースコードよりも全然読みづらい事になるでしょう。*2 *3 *4
まー、確かに便利だというのは確かなんすが、やりすぎは毒ですよという事で。

*1:でも、これはDIコンテナじゃないとできないかと問われれば、決してそんなことはなく、個人的にはJNDIの方がすきです

*2:自分の知っているDIコンテナだと、XMLか、Javaのpropertiesファイル形式かで書くものがほとんど。

*3:DIコンテナの設定内でスクリプトが書けるものがあると面白いかも?と思ったが、3秒で覚えることが増えるのは面倒だと思った。

*4:Antのbuild.xmlにGroovyのコードが書かれていた事があった。XMLの中のスクリプト言語は読み辛いし、デバッグもしづらかった。