DI (Dependency Injection)

DI란?

• Dependency Injection의 약자로 의존성 주입이라고 한다
• 객체(빈)들 간의 의존관계를 외부에서 결정하고 주입하는 것

동작과정

• DI는 스프링 프레임워크에서 지원하는 IoC의 형태로 객체(빈) 사이의 의존관계를 빈 설정정보를 바탕으로 DI 컨테이너가 자동으로 연결

장점

• Unit Test 용이 => 의존성이 낮아지기 때문
• 코드 재활용성 증가 => 하나의 객체에 의존하지 않기 때문
• 객체 간의 의존성(종속성)을 줄이거나 없앨 수 있음
• 객체 간의 결합도를 낮추면서 유연한 코드 작성 가능

DI (의존성 주입) 방법

1. 생성자 주입 (Constructor Injection)
    - 생성자의 호출 시점에 '1회' 호출 되는 것이 보장된다. 그렇기 때문에 주입받는 객체의 변화가 없거나 반드시 객체의 주입이 필요한 경우에 강제하기 위해 사용이 가능 (생성자가 1개만 있을 경우 @Autowired 생략 가능)
2. 수정자 주입 (Setter Injection)
    - Setter를 이용하여 의존 관계를 주입하는 방법이다. 주입받는 객체가 변할 수 있는 경우에 사용
   (만일, @Autowired로 주입할 대상이 없는 경우 오류 발생 => 빈에 존재 하지 않을 경우
    주입 할 대상이 없도록 하려면 @Autowired(required = false)를 통해 설정 가능)
3. 필드 주입 (Field Injection)
    - 필드에 바로 의존 관계를 주입하는 방법으로 코드가 간결해져 과거에 많이 이용된 방법. 하지만, 필드 주입은 외부에서 변경이 불가능하다. 즉, 테스트 코드에서 Mock 데이터를 사용하여 주입하게 되면 안된다는 말이다.
   또한, 필드 주입은 DI 프레임워크(스프링)가 존재해야지만 사용이 가능하다. 그래서 사용을 지양한다. => 어플리케이션의 작동과 무관한 테스트 코드나 설정을 위해서만 사용하는 것이 좋다.

생성자 주입 방법을 권장하는 이유

1. 객체의 불변성 확보
2. 테스트 코드의 작성
3. final 키워드 작성 및 Lombok의 결합
    - 위의 세 가지 방법 중 생성자 주입만이 객체의 생성과 동시에 의존성 주입이 이루어진다.
   그래서 final 변수를 할당 할 수 있다. 나머지 방법은 객체 생성 후 의존성 주입 함수 호출로 이루어지기에 final 변수를 할당할 수 없다.
4. 순환 참조 에러 방지
    - 클라이언트 구동 시, Bean에 등록하기 위해 객체를 생성하는데 이 때 순환참조를 찾으면 바로 에러를 발생시킨다.
   만약, 수정자 주입을 사용했다면 해당 객체를 사용하기 위해 의존성을 주입했을 경우 에러가 나서 처음에는 모른 상태에서 나중에 발견할 수도 있는 경우가 생긴다.
   이를 방지하기 위해 생성자 참조를 사용해야 한다.