DI（依存性注入）をアプリケーション設計に取り入れる主な目的として正しいものはどれですか？
1〜4キーで選択、Enterで回答できます
解説
正解は「クラスが利用する部品を外部から受け取る形にして」です。DI（Dependency Injection、依存性注入）は、あるクラスが必要とする部品（依存オブジェクト）を自分で new せず、外部から渡してもらう設計手法です。これにより結合度が下がり、差し替えやテストがしやすくなります。コードで見る違い// DI なし: UserService が MySqlUserRepository に直接依存している class UserService { constructor() { this.repo = new MySqlUserRepository(); // 実装が固定され差し替えられない } } // DI あり: 使う側から渡してもらう（コンストラクタインジェクション） class UserService { constructor(repo) { this.repo = repo; // 何が渡されるかは呼び出し側が決める } } // テストではダミー実装を渡せる const service = new UserService({ findById: async () => ({ id: 1, name: 'テスト' }) });誤答が指している内容「クラス間の依存関係そのものを取り除き」は誤りです。DI で消えるのは「依存オブジェクトを自分で生成する責任」であって、依存自体は残ります。UserService はリポジトリを必要とし続けます。「依存ライブラリのバージョンをフレームワークが解決し」は、npm などのパッケージ管理の話で、DI とは別の領域です。同じ「依存」という語ですが意味が異なります。「オブジェクトの生成タイミングを遅らせて」は、DI コンテナが結果的に遅延生成を行うことはありますが、DI の目的ではありません。DI コンテナがなくても DI はできますNestJS や Spring のような DI コンテナ（依存を自動で組み立てて渡す仕組み）を導入して初めて DI になる、と思われがちですが、そうではありません。上のコードのように引数で渡すだけでも立派な DI です。小規模なアプリではコンテナを入れず、エントリポイントで手動で組み立てるほうが見通しが良い場合もあります。参考Inversion of Control Containers and the Dependency Injection patternProviders | NestJS Documentation