依存性注入のイメージはレンタカー？

あなたは依存性注入のイメージを持っていますか？
僕が持っているイメージは、レンタカーです。

依存性注入はレンタカーを借りることに似ている

あなたはレンタカーを借りたことがありますか？
レンタカーでなくても、他の人から車を借りたことがありますか？
そのとき、すぐに運転できましたか？
できましたよね？

なぜですか？

車を運転するには、ハンドル、アクセル、ブレーキ、シフトレバーを操作すればいいことを知っているからです。

この、ハンドル、アクセル、ブレーキ、シフトレバーはインタフェースということができます。
我々は、自動車教習所の技能教習の１時限目にトレーチャーというシミュレータを用いて、このインタフェースについて学びます。
こうすることで、２時限目以降は実車を動かすことができます。また、免許を取ってからレンタカー屋さんに行き、軽トラックやフェラーリを借りれば、それらの車を運転することができるのです。

依存性注入において、この軽トラックやフェラーリが依存性に相当し、借りることが注入に相当します。

車を運転することの基本的な目的は、移動することです。
移動するだけなら、軽トラックでもフェラーリでもどっちでもいいんです。
でも、燃費を良くしたいとか、荷物を積みたいとか、速く移動したいとか、他人の目に良く映りたいとかという、移動以外の目的もあるので車種を選ぶことになります。

ここで、車種によって、インタフェースが全く違ったらどうなるでしょう？
フェラーリが飛行機のように、手でアクセルを操作し、足で方向を変えるようになったらどうします？
困りますよね？いくら格好良くても、借り賃が安くても借りれませんよね？

つまり、どんな高性能の車を設計するにしても、基本的に運転に関するインタフェースを変えてはいけないのです。

依存性注入用のメソッドもインタフェースを変えないように作る

依存性注入におけるメソッドもインタフェースを変えないように作ります。
こうすることで、メソッドを使う側は、インタフェースに合うようにコーディングをしておけば、メソッドの中がブラックボックスであっても問題ありません。

ドメイン駆動設計という手法があります。この方法は、現場の知識をモデル化したドメイン層が、他の層の都合で変更させられることのないように設計します。
ざっくり言えば、ドメイン層がインタフェースを決めて、それ以外の層が、そのインタフェースに合わせてメソッドを作ります。こうすることで、設計思想が実現されます。

ドメイン駆動設計で、依存性注入は必須の技術です。

まとめ

依存性注入は、レンタカーとの対比で考えることで、なんとなくイメージがつかめたのではないかと思います。次の投稿で、簡単なサンプルを示したいと思います。