DIコンテナってなに？
DIコンテナ（Dependency Injection Container：依存性注入コンテナ）は、アプリケーション内の部品（クラスのインスタンス）の生成、管理、およびそれらの部品間の連携（依存関係）を自動的に行ってくれる「管理倉庫」または「秘書役」のようなものです。
Spring Frameworkでは、このコンテナがアプリケーションの中心的な役割を果たします。
また､DIコンテナは、通常、アプリケーションが起動する時に作られ､アプリケーションが正常にシャットダウンされる時、DIコンテナも破棄されます。
DIコンテナの役割のイメージ
DIコンテナの役割を理解するために、従来のJavaアプリケーション開発と比べてみましょう。
従来の開発（DIコンテナなし）
新しい部品（クラス）を使いたい場合、開発者が手動で必要な場所すべてにその部品を作る（new 演算子）必要がありました。
問題点:
手間: 部品が増えるほど、new を書く手間が増えます。
結合度の高さ: クラスAがクラスBを直接 new すると、クラスAはクラスBに強く依存してしまい、後でクラスBを別の実装に替えたいとき（例：テスト用のモックに替えたいとき）に、クラスAのコードも変更が必要になります。
public class UserService {
// 😫 直接newしているため、「データベース」実装に強く結合してしまう
private DatabaseUserRepository repository = new DatabaseUserRepository();
public void registerUser(User user) {
repository.save(user);
}
}
テストでデータベースを使いたくない場合でも、UserService のコードを書き換えて new MockUserRepository() に変える必要があります。つまり、部品の変更が利用側の変更を強制します。
DIコンテナを使った開発（Springなど）
開発者は部品を作ること（new）をやめ、「この部品が欲しい」と宣言するだけになります。
DIコンテナの作業:
開発者が「このクラスは部品です」と指定（@Component や @Service などのアノテーション）。
コンテナはそれらの部品（インスタンス）を自動的に生成し、倉庫（コンテナ）で管理します。
あるクラスが別の部品を欲しがっている（@Autowired やコンストラクタ）のを見つけると、倉庫から適切なインスタンスを取り出し、自動的に渡してくれます（依存性の注入）。
この働きによって、部品間の依存関係がコンテナによって外部から（外側から）注入されるため、「依存性の注入（DI）」と呼ばれます。
例えば
サービス層はインターフェースを介して「欲しい」と宣言するだけで、具体的なインスタンスの生成はコンテナに任せます。
// ユーザー保存の契約（インターフェース）
public interface UserRepository {
void save(User user);
}
// 実際のデータベースに保存する実装
@Repository
public class DatabaseUserRepository implements UserRepository { /* ... DB接続コード ... */ }
// サービス層（利用側）
@Service
public class UserService {
// 😊 インターフェースで宣言し、あとはSpringにお任せ
private final UserRepository userRepository;
// コンストラクタで「欲しい」と宣言する（コンテナが注入してくれる）
public UserService(UserRepository userRepository) {
this.userRepository = userRepository;
}
// ...
}
このとき、DIコンテナが裏側で以下の作業を実行しています。
-
コンテナが @Service の
UserServiceを読み込む。 -
UserService がコンストラクタで
UserRepositoryを要求していることを知る。 -
コンテナが、@Repository が付いた
DatabaseUserRepositoryのインスタンスを生成する。 -
その生成したインスタンスを
UserServiceのコンストラクタに自動で渡す（注入する）。
これにより、UserService はどの具体的なリポジトリ実装を使っているかを知らなくてもよくなります。
DIコンテナを使うメリット
1. 疎結合の実現（コードが柔軟になる）
DIコンテナを使えば、設定やプロファイル（環境）に応じて、注入する具体的な部品を簡単に変更できます。
本番環境
@Profile("prod") と設定された DatabaseUserRepository を注入する。
開発環境
@Profile("dev") と設定された、メモリ上でデータを保持する軽量な InMemoryUserRepository を注入する。
UserService のコードを一切変更することなく、アプリケーションの起動設定を変えるだけで、使用するデータベース実装を本番用と開発用で切り替えられます。これはDIコンテナが外部（設定）から依存関係を制御しているからです
2. 再利用性の向上（テストの劇的な簡略化）
コンテナが依存関係を管理しているおかげで、テストが非常に簡単になります。
例えば
UserService のビジネスロジックだけをテストしたいとき、実際のデータベースへの接続は不要（むしろテストを遅くする）です｡
// テストコード
@ExtendWith(MockitoExtension.class)
class UserServiceTest {
// 偽物（モック）のリポジトリをDIコンテナのフリをして用意
@Mock
UserRepository mockRepository;
// モックを使ってUserServiceのインスタンスを生成（コンストラクタインジェクションを利用）
@InjectMocks
UserService userService;
@Test
void ユーザーが登録されているか確認できる() {
// モックに「findByEmailが呼ばれたら、この偽物のユーザーを返せ」と指示
when(mockRepository.findByEmail("test@example.com")).thenReturn(new User("Test User"));
User found = userService.getUserData("test@example.com");
// 実際のロジックをテスト
assertThat(found.getName()).isEqualTo("Test User");
}
}
DIコンテナの仕組み（コンストラクタで依存オブジェクトを受け取る構造）をテストツール（Mockitoなど）が活用することで、実際の部品ではなく偽物（モック）を簡単に注入でき、テストの信頼性と速度が大幅に向上します。
3. 部品のライフサイクル管理
コンテナは、いつインスタンスを生成し（通常はアプリケーション起動時）、いつ破棄するかを自動で管理してくれます。多くの部品はシングルトン（インスタンスが一つだけ）として管理されるため、メモリの効率化にもつながります。
つまり､そのクラスのインスタンスをアプリケーション全体でたった一つだけ生成し、それを使い回すということを意味します。
具体例（ロガーとメモリ効率）
アプリケーション内で、ログ出力を行うための LoggerService があるとします
1.部品の定義
@Service // このアノテーションでSpring Beanとして登録
public class LoggerService {
public void log(String message) {
System.out.println("[LOG] " + message);
}
}
2.DIコンテナの動作
-
起動時: DIコンテナは、
LoggerServiceのインスタンスを一つだけ生成し、メモリ上に保持します。 -
利用時:
UserServiceやProductControllerなど、100個の異なるクラスがLoggerServiceを要求した場合でも、コンテナは最初に作ったその一つのインスタンスを使い回して注入します。
シングルトンなし（従来の new）の場合
もしDIコンテナがなく、すべてのクラスが手動で new していたらどうなるでしょうか。
public class UserService {
// ❌ 使うたびにLoggerServiceのインスタンスが生成され、メモリを無駄に消費する
private LoggerService logger = new LoggerService();
// ...
}
この場合、UserService が100個、ProductService が100個あれば、メモリ上に LoggerService のインスタンスが200個も生成されてしまいます。
シングルトン（DIコンテナ）の場合
DIコンテナを使えば、常にインスタンスは一つだけです。
-
インスタンス数: 1個
-
メリット:
-
メモリ効率: 無駄なインスタンス生成を防ぎ、メモリ使用量を抑えます。
-
起動速度: アプリケーション起動時に一度だけインスタンスを初期化すれば、実行中は初期化のオーバーヘッドがありません。
-
別のスコープ：プロトタイプ（Prototype）
シングルトンが不適切な場合（例：ユーザーごとの状態を持つショッピングカートなど）、DIコンテナに「要求されるたびに新しいインスタンスを作ってほしい」と指示することも可能です。このスコープをプロトタイプといいます。
// 要求されるたびに新しいインスタンスを生成する設定
@Scope("prototype")
@Component
public class ShoppingCart {
// ユーザーAとユーザーBで中身が異なってほしいので、シングルトンにしてはいけない
private List<Item> items = new ArrayList<>();
// ...
}
このように、DIコンテナは部品の種類や目的に応じて、インスタンスの生存期間を柔軟に制御し、アプリケーション全体の効率と安全性を高めています。