dependency injection とは？協力オブジェクトを外部から供給する

dependency injection (DI) は、コンポーネントが依存物を自分で生成するのではなく、外部から供給します。

クラスが自分の協力オブジェクト、データベース client、HTTP サービスを自分で構築すると、その具体的な選択に溶接され、テストしにくくなります。dependency injection はそれを逆転させます。依存物は外から渡されます。コンポーネントはインターフェースに依存し、どの実装を提供するかは呼び出し側が決めます。最大の見返りは、結果をどれだけきれいにテストできるかに現れます。

制御の反転

コンポーネントが必要なものを構築しに出向くのではなく、必要なオブジェクトが、コンストラクタ、setter、あるいは framework を通じて手渡されます。コンポーネントは何に依存するかを宣言し、何を提供するかは別のものが決めます。

なぜ役立つのか

テスト容易性: 実物の依存物の代わりに fake や mock を注入する。
柔軟性: consumer を変えずに実装を入れ替える。
明確な依存関係: コンポーネントが必要なものを前もって宣言する。
具体クラスへのより緩やかな結合。

テストでの見返り

DI こそが、実物の協力オブジェクトなしでコンポーネントを unit-testable にします。データベースや外部サービスの test double を注入するため、テストは高速に、決定的に、そして分離して動きます。ネットワークも、実物のデータベースも、共有状態もありません。

より高速で信頼できる CI

遅かったり flaky だったりする依存物に fake を注入するテストは高速に動き、外部サービスがダウンしても壊れません。これにより CI スイートが高速かつ安定に保たれ、より遅い integration テストは実物の結線のために取っておけます。

どこで線を引くか

DI はツールであって目的ではありません。些末な依存物を過剰に注入すると、コードを分かりにくくする間接層が増えます。入れ替えたい・偽装したいもの、network client や外部サービスを注入し、残りは素直な構築に任せましょう。

ウォームな runner での高速な unit スイート

DI 駆動の unit テストが高速なのは、まさに実物の依存物を避けるからです。ウォームな runner（Latchkey など）は、スイート全体を端から端まで高速に保つため、DI がもたらす速度が runner の起動で失われません。

重要なポイント

dependency injection は、コンポーネントに依存物を構築させるのではなく供給する。
実物の協力オブジェクトの代わりに fake を注入することで、コンポーネントを分離してテスト可能にする。
入れ替えたい・偽装したいものを注入する。些末な依存物を過剰に注入しない。