それを実装するためにはどのような工夫が必要かまでを検討します。実装が難しいパターンも出てくるかもしれません。その際は、なぜ難しいのかまでを検証します。規模のソフトウェアを実装するにあたって、ソフトウェアエンジニアが共通して利用する手法がいくつかあると思います。ポピュラーな手法の一つであり、保守運用まできちんと耐えうるソフトウェアの設計をしたいとなったときに、まず真っ先に候補に上がる手法でしょう。どのように行えばよいのでしょうか。どのように扱われているかを確認します。当てはめるとどのように実装できる可能性があるかを紹介します。是非についてはさまざま議論があるようです。手法を利用せずとも柔軟に疎結合なコードを書くことができます。不要、という意見もあります。有効な手法であると考えています。必要はないと考えており、そうした議論については適宜補足を入れる想定です。氏が最初に提唱し始めたようです。pattern」[*4]という記事により、一般に用語が普及し始めたようです。相当の概念が議論されていました。Control」という名称がわかりにくいなどの理由で、有識者同士で適切な用語を議論しあったようです。Injection」という用語でした。何をするものなのかを説明します。構成する概念の説明をします。はじめとする技術的な概念は、どのような問題を解決し、利用者にどのようなメリットをもたらすのかを知るべきでしょう。最終的に何をするのかという点については、下記2つから説明できると筆者は考えています。コンポーネントを外側から注入し、コンポーネント同士を疎結合にする。依存関係を自動で解決し、コンポーネント管理の手間を少なくする。導入することで、コンポーネント同士を疎結合にすることができます。コンポーネントというのは詳しくは後ほど説明しますが、オブジェクトならオブジェクト、クラスならクラスと考えてください。このコンポーネントを外側から注入するようにし、コンポーネント同士を疎結合にすることができます。導入すると、コンポーネント間の依存関係をある程度自動で解決できるようになります。これにより情報の一元管理の実現や依存関係の管理コストの低減を期待できます。コードを通じて簡単に例を示します。今回は2つのコンポーネントと1つのデータを用意します。ユーザーは次のようなデータ構造をしているものとします。これらを「コンポーネント」と呼びます。実装は次のようになっているものとします。コンストラクタの内部処理を何か用意するかもしれない。ユーザーのデータの更新処理を書く。次のようになっているものとします。メソッドを呼び出しします。情報が保持されている必要があります。外から渡されて(注入されて)います。利用しておくと、使う側(UserService)は、使いたいオブジェクト(UserRepository)がどのような依存解決をされたのかをあまり気にする必要はありません。生成済みのコンポーネントを渡すだけでよくなるためです。コンストラクタにある使いたいコンポーネントをそのまま呼び出すのみです。インスタンスを生成します。値をコンストラクタに入れます。コンテナと呼ばれる機能を利用できる場合があります。コンテナというのはさしあたっては、自動で依存関係を解消してくれるブラックボックスのようなものと考えてください。コンポーネントの数が増え、依存関係を整理する対象が増えると必然的にコンポーネント生成のために依存を渡す管理コストが膨らみます。コンテナを利用すると、こうした依存関係をプログラマが手で整理することはなく、マクロやリフレクションなどの機能により自動的に解決した状態にすることができます。これにより大幅に手間が軽減されます。コンテナをサポートしています。コンテナで書き換えてみます。実装を書き換えてみたものです。される(あるいはする)対象として使用できるようになります。コンストラクタの内部処理を何か用意するかもしれない。ユーザーのデータの更新処理を書く。