プロジェクト依存関係の設定
Mavenベースの環境でSpring Coreライブラリを導入する場合、以下のようなPOM構成を採用します。
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>jp.tech.demo</groupId>
<artifactId>spring-ioc-demo</artifactId>
<version>1.0.0</version>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>5.3.30</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>17</source>
<target>17</target>
</configuration>
</plugin>
</plugins>
</build>
</project>
XMLによるコンテナ設定とビーン定義
SpringのIoCコンテナは、外部設定ファイルで管理対象のオブジェクト(ビーン)とその依存関係を宣言的に定義します。主な設定特性は以下の通りです。
- スコープ(scope):
singleton(デフォルト、コンテナ起動時に1回だけ生成)、prototype(参照取得時に毎回新規生成)。Web環境ではrequestやsession、global-sessionも利用可能です。 - ライフサイクル: シングルトンビーンはコンテナと同期して生成・破棄されます。プロトタイプビーンは使用後にJVMのガベージコレクションによって回收されます。
依存関係の解決手法として、「コンストラクタ経由」「Setterメソッド経由」「コレクション注入」の3つのパターンを実装します。
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
https://www.springframework.org/schema/beans/spring-beans.xsd">
<!-- コンストラクタインジェクション -->
<bean id="userService" class="jp.tech.demo.service.UserService">
<constructor-arg name="repository" ref="userRepository"/>
<constructor-arg name="cacheEnabled" value="true"/>
</bean>
<bean id="userRepository" class="jp.tech.demo.repository.UserRepository"/>
<!-- セッターインジェクション -->
<bean id="reportGenerator" class="jp.tech.demo.util.ReportGenerator" scope="prototype">
<property name="outputFormat" value="PDF"/>
<property name="theme" value="corporate"/>
</bean>
<!-- コレクションデータの入力 -->
<bean id="systemConfig" class="jp.tech.demo.config.SystemConfig">
<property name="enabledModules">
<set>
<value>auth</value>
<value>logging</value>
<value>metrics</value>
</set>
</property>
<property name="defaultTimeoutMs">
<list>
<value>5000</value>
<value>10000</value>
<value>15000</value>
</list>
</property>
<property name="routingRules">
<map>
<entry key="/api/v1/users" value="readReplica"/>
<entry key="/api/v1/orders" value="primaryDB"/>
</map>
</property>
</bean>
</beans>
コンテナの初期化とビーン取得
設定ファイルを解析してIoCコンテナを起動し、管理下のオブジェクトを取得します。代表的な実装として、クラスパス配下から設定を検索するClassPathXmlApplicationContextを使用します。コンテナ自体はApplicationContextインターフェースとして扱え、シングルトンおよびプロトタイプの両方をサポートします。
package jp.tech.demo.runner;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
public class AppBootstrapper {
public static void main(String[] args) {
ApplicationContext context = new ClassPathXmlApplicationContext("spring-config.xml");
// コンストラクタ注入されたサービスの取得
var userService = context.getBean("userService", jp.tech.demo.service.UserService.class);
System.out.println("UserService initialized: " + userService);
// セッター注入+プロトタイプスコープの確認(別インスタンスが生成される)
var reportA = context.getBean("reportGenerator", jp.tech.demo.util.ReportGenerator.class);
var reportB = context.getBean("reportGenerator", jp.tech.demo.util.ReportGenerator.class);
System.out.println("Prototype verification: " + (reportA != reportB));
// コレクション注入された設定クラスの検証
var sysConfig = context.getBean("systemConfig", jp.tech.demo.config.SystemConfig.class);
System.out.println("Active modules: " + sysConfig.getEnabledModules());
System.out.println("Timeout settings: " + sysConfig.getDefaultTimeoutMs());
}
}
制御の反転(IoC)と依存性注入の原理
従来のオブジェクト指向設計では、各クラスが自身の依存先を内部的にnew演算子などで直接インスタンス化していました。この手順はモジュール間の結合度を高め、保守性やテスト効率の低下を招きます。
Springが導入するIoC(Inversion of Control:制御の反転)は、オブジェクトの生成フロー、結合タイミング、生存期間をアプリケーションコードから隔離し、専用に用意されたコンテナ側に委譲する設計思想です。これにより「具体的な実装クラスに依存せず、抽象または外部設定に対して動作する」という疎結合な構造が保証されます。
DI(Dependency Injection:依存性注入)は、このIoCを実現するための標準的な実装手法です。コンテナ側が準備した依存オブジェクトを、呼び出し側のコンストラクタ引数やSetterメソッドを通じて受け渡す仕組みを提供します。開発者は内部状態の組み立て処理から解放され、コアビジネスロジックの実装や、ユニットテスト時のスタブ・モック注入に専念できるようになります。