自動的に渡ってくるようになります。使う側を確認してみましょう。いう適当なクラスを作ってみることにします。このコードからもわかるように、インスタンス生成に関する知識を一切コードに書くことなく裏で自動で解決済みのインスタンスが渡ってきます。使用して処理を実装していくだけです。コンテナで解決済みのインスタンスが来ている。アプリケーションの起動に関する記述のみで済むようになります。コンテナを用いない例と比較すると一切インスタンス生成に関するコードを記述しなくて済んでいることわかります。コンテナが裏でそのような依存解決を自動で行っているためです。コンストラクタの引数にさらに依存するリポジトリが増えた場合に、コンストラクタの引数とフィールドを追加するだけで済むようになることです。コンテナがあればその芋づる式の修正を抑止できます。コンテナは必ずしも利用する必要はないと筆者は考えています。DI」と呼んでいます。用いる傾向にあります。連載の後半で紹介しようと思っていますが、代わりに簡単な生成器を作って生成する行為そのものをそこにまとめておく傾向にあるように思います。最近ではほとんどのケースでコンストラクタインジェクションを利用するようになっているかと思われます。コンストラクタインジェクションは、先ほどサンプルコードで説明したやり方です。依存先のコンポーネントに利用したいコンポーネントをコンストラクタ経由で渡すことを言います。コンストラクタインジェクションは、インスタンス生成時にどのコンポーネントを利用するかを決定し、インスタンス生成後は変更を加えません。これにより、生成されたインスタンスをイミュータブルに保ちやすくなるというメリットを享受できます。実はその他にもいくつか手法があります。元記事では「セッターインジェクション」と「インタフェースインジェクション」が紹介されています。Patterns』では、「プロパティインジェクション」なる手法も紹介されています。コンテナは用いないものの、少ない手間で注入されるコンポーネント間の依存関係をうまく解決できる手法です。いう手法自体はさまざまなプログラミング言語で表現可能です。コンテナを利用するかどうかはプログラミング言語に依るように思われます。Principle」というものがあります。して内包的に説明されている場合もあるようですが、今回は分けて考えます。Injection」について紹介してきました。Inversion」と呼ばれるルールが存在します。「依存性逆転の原則」と表現されます。略されることが多いかもしれません。際にインタフェースを利用して依存コンポーネントを注入します。コードでは、コンストラクタを経由して具体的なクラスを注入していました。このクラスに、さらに「インメモリでキャッシュとして使いたい」という機能をもつ新しい亜種が誕生したとして、そのコンポーネントを注入したいとなったとします。すると、これまで具体的なクラスを利用してコンポーネントを注入していたため、コンストラクタの型を書き換える必要が出てきます。コンストラクタの内部処理を何か用意するかもしれない。ユーザーのデータの更新処理を書く。先ほどまでは下記を利用していた。このコンストラクタの型をインタフェースに差し替えます。インタフェースに差し替えることで、コンストラクタの型は変更の必要がなくなります。いうインターフェースを用意します。