DI(Dependency Injection : 의존성 주입)에 대하여

❗DI 주입 구현

개념적 분류 2가지

• Setter Based Injection (수정자를 통한 주입)
  • Controller 클래스의 특정 메소드가 Service(인터페이스) 객체에 의존하는 경우→ Service 구현체를 메소드에 넘겨줘야 함 (=DI)
  • Service 구현체 ⇒ setService()라는 setter을 정의해 Controller 클래스에 주입→ 필요로하는 메소드에서 그 구현체를 사용 가능.
  • 이때 NullPointException이 발생할 수 있음 (∵ Service 구현체 주입해주지 않아도 Controller 객체 생성 가능)
  • 🤔 ... Service 구현체가 주입 되지 않으면 아예 객체 생성 자체를 방지할 순 없을까?

• Constructor based Injection (생성자를 통한 주입)
  • 그래서 등장했다. 생성자를 통한 주입..
  • 객체 생성 담당 == 생성자 == 그럼 얘부터 브레이크를 걸면 되겠군
  • Constructor의 인자로 아예 Service 구현체를 줘버려 → Controller 객체에 세팅함
    • 따라서 Service가 주어지지 않으면 Controller 객체 자체가 생성되지 않는다는 것
    • ⇒ NullPointException 발생 방지 (null을 주입하지 않는 이상) + 컴파일 타임에 오류 캐치 가능 (Controller 객체 자체가 생성 안되니까)
  • final을 사용 가능함 (final로 선언된 변수 → 반드시 선언과 함께 초기화 돼야 함 ∴ setter은 X)

➕

• Field Injection (Spring에서 가능)
  • Setter based Injection과 유사한 방식으로 진행
  • 스프링 컨테이너가 아닌 외부에서 호출해 주입할 방법이 없음

 

참고 자료

https://yaboong.github.io/spring/2019/08/29/why-field-injection-is-bad/