IoC 컨테이너 & DI

IoC

객체가 자신이 사용할 객체를 직접 생성 및 조작하는 작업을 하지 않고, 객체의 생성을 ‘특별한 관리 주체’에게 위임

즉, 사용자가 객체를 직접 생성하지 않고, 다른 주체가 객체의 생명주기를 컨트롤한다는 개념이다.

라이브러리를 사용하는 애플리케이션 코드는 애플리케이션 흐름을 직접 제어하지만, 프레임워크는 애플리케이션 코드가 프레임워크에 의해 사용된다.

 

ApplicationContext

일종의 IoC 컨테이너이다. 객체에 대한 생성과 조합을 가능하게 하는 프레임워크이다.

ApplicationContext는 BeanFactory를 상속한다.

BeanFactory는 객체에 대한 생성, 조합, 의존관계설정 등을 제어하는 IoC 기본 기능을 담당한다.

 

Configuration Metadata

ApplicationContext는 실제 만들어야할 빈 정보를 Configuration Metadata로부터 받아온다.

이 Metadata로 객체를 생성 및 구성한다.

 

Dependency Injection

IoC를 구현하는 하나의 패턴

어떤 객체를 사용하는 주체가 객체를 직접 생성하는게 아니라 객체를 외부(Spring)에서 생성해서 사용하려는 주체에 주입시켜주는 방식이다.

• setter DI: 한 번 세팅하면 중간에 바꿀 이유가 없는데도 불구하고 바뀔 가능성이 생긴다는 단점이 있음
• field DI: 외부 접근이 불가능하여 테스트 코드 작성 시 불편해짐
• constructor DI

 

생성자 기반 의존관계 주입을 선택해야 하는 이유?

1. 초기화 시에 필요한 모든 의존관계가 형성되기 때문에 안전함
   1. 필요한 의존관계가 생성자에서 필수로 요구된다면, 객체 생성 시에 모든 필요한 의존관계를 주입받았다고 확신할 수 있음
   2. 나중에 참조하는 필드가 없어서 null pointer exception이 발생할 확률이 없다.
2. 잘못된 패턴을 찾을 수 있게 도와줌
   1. 수 많은 의존관계가 붙어 있는 클래스가 있을 시 관심사의 분리가 필요함을 미리 인지할 수 있음
3. 테스트를 쉽게 해줌
   1. 쉽게 Mock 객체를 전달해줄 수 있음
   2. setter나 필드 기반이면 실수로 누락될 가능성이 있음
4. 불변성을 확보함
   1. final 키워드를 통해 한 번 만들어진 의존관계가 변하지 않도록 보장해줌
   2. 상태가 변하지 않는 불변 객체를 만들 수 있고, 이는 multi-thread 환경에서 thread safe를 보장함

 

@Component와 @Bean의 차이

@Component는 클래스 레벨에 사용하고, @Bean은 메소드 레벨에 사용하고, @Configuration과 꼭 함께 사용해야한다.

@Component는 주로 개발작 직접 컨트롤할 수 있는 클래스에서 사용하고, @Bean은 외부 라이브러리를 활용해야하는 상황에서 사용합니다.