まえがき

DI(Dependency Injection)という一種のデザインパターンがある。
日本語では依存性の注入というかなり意味のわからない訳になっている。

このパワーワードを理解することを目標に頑張って記事を書きます。

依存性の注入という言葉が混乱を生む一番の原因

依存性の注入(DI)
これを私が理解できる言葉に置き換えるとしたらこうなる。

プログラムに具体的な処理を書くのを辞めましたパターン

依存性の注入じゃなくて具体性の削除の方が正しいと思う。

あえて名前を付けるならこうなる
Concreteness Deletion(具体性の削除)

こんな風にかっこつけて要約して名前つけたりする

すると

なにこれ、意味わかんない難民が沢山生まれる。

うん、かっこつけなくていい

プログラムに具体的な処理を書くのを辞めましたパターン

これでよくない？だめ？

DIのメリット

具体的な事を書かないので書くことが減ります。

DIのデメリット

具体的な事を書かないのでコードだけ見ても何が起きてるか意味がわからなくなります。

依存性ってつまりなんだという話

元ゲームプログラマーなのでゲーム系のネタで考えてみる。
例えばゾンビ(敵)を作ろうとなったとき

class Zombie extends Enemy{

    private String name = "ゾンビ";
    private int maxHp = 999;
    private int hp = 999;

}

インスタンス変数に具体的な値を書いているので
パッと見で敵の名前セットしてるなー、最大HPセットしてるなーってわかると思う

大雑把に言えば、こういう具体的な部分を依存性と呼んでいる
(依存性じゃなくて、具体性と呼んでくれればまだよかったものを。。。)

依存性の注入というより具体性の注入

敵の名前とか最大HPとかのデータをテキストファイルに書いておいて
プログラムでその内容を読み込んで使えばいいじゃんという流れになる

名前やHPを変えたいときはプログラムじゃなくて
テキストファイル(つまりは設定ファイル)の内容を変えるだけでいい

プログラムは変える必要がない
つまり再コンパイルがいらないのである
これは素晴らしいね

でかいプロジェクトだとコンパイルで１時間とかあるからね
プログラムちょっと変えて１時間コンパイルは耐えがたい

というわけでデータはプログラム内に書かない
テキストファイルやらデータベースやらに保存して
そのデータをプログラムで読み込んで使うのが主流となった。

これがDIの根幹というか
データを外に出して(ファイルとかに保存して)、そのデータを改めてプログラムに注入
依存性の注入というか具体性の注入って事じゃなかろうか

DIについて個人的な感想

最近のDIは書くこと減らそうとしすぎて
わけわからんレベルに達している気がします。
特にアノテーション禁術はカオスすぎる。

DIはプログラムを整理しようとして頑張っていたら
整理しすぎてしまって、正直やりすぎたわぁ
ってなったパターンなんだと個人的には思っています。

正直DIって呼ぶにふさわしいと思うもの

最近だといろんなパッケージを組み合わせて１つのアプリケーションを作るというのが当たり前になってきました

つまり最近のシステムは何かしらのパッケージがないと動かない
つまりシステムは何かしらのパッケージに依存している。

パッケージというのは腐る程存在していて
一体どれを使えばいいんだーっていうのがわからなくなってきたので
最近は細かい事は勝手にいい感じにやってくれるパッケージ管理ツールというのがある。
言語別にみるとだいたいこんな感じ。

Java → maven or gradle
PHP → composer
node.js → npm
Ruby → gems
Python → pip

これらのツールはシステムで使うパッケージ(プログラム)を
勝手にダウンロードして使えるように組み込んでくれる

これこそ依存性(依存するパッケージ)の注入やんって思うわけでした。