[TIL#33] 개념 정리] DI, IoC

1. 들어가며

 이전의 TIL에서 DI와 IoC에 대해서 정리를 했었지만, 그때보다 개념이 좀 더 확실하게 잡혀서 다시금 기록하려고 한다.

 

2. DI 와 IoC

1. IoC

 현실에서의 패키지여행이라는 예시로 설명해 보겠다. 패키지여행에서 손님의 역할은 관광이다. 패키지여행을 신청하면 언제, 어떤 곳을 갈지, 어떤 식당을 갈지 등 모든 일정은 여행사가 제공해 주는 것을 따라야 한다. 손님은 여행사에게 여행을 맡기고 온전히 관광에 집중하면 된다. 여행사라는 별도의 설정자를 통해 일정을 주입받고 오롯이 관광에 집중하는 것이다. 이렇듯 클라이언트(손님)가 여행을 직접 제어하는 것이 아니라 시스템(여행사)이라는 외부에서 여행을 제어하고 관리하는 것이 바로 제어의 역전 IoC이다.

 

 

2. DI

 그런데 위에서 말한 일정은 언제든지 변경될 수 있다. 여행 도중 비다 쏟아진다거나, 식당의 휴업 등 다양한 원인으로 일정이 변경될 수 있다.

 

하지만 여행사가 손님에게 제공하는 일정이 바뀌어도 손님의 관광에는 지장이 없다. 이렇듯 실행 시점에서 실제 의존 관계가 정해지고 연결되는 것을 의존관계 주입, DI이라고 한다.

 

관계를 정리하면 다음과 같다.

 

코드상에서 여행사의 역할을 해주는 것을 DI컨테이너 혹은 IoC컨테이너라고 하며 보통 스프링이 이 역할을 대신해 준다.

 

개인적인 생각으로 DI는 IoC를 달성하기 위한 기법 중 하나이다.

 

3. DI 적용 방법(방식)

DI는 보통 3가지 방법으로 구현할 수 있다. 각 특징은 다음과 같으며 그 중 생성자 주입 방법에 대해서만 언급하겠다.

• Field 주입
  • 코드가 간단하지만, 외부에서 변경이 불가능하다. 특히 테스트 코드작성이 어려워진다.
  • 권장되지 않는다.
• Setter 주입
  • 외부에서 변경이 가능하나, 메서드를 호출하여 자유롭게 변경이 가능하기에 안정성에 위협이 된다.
  • 권장되지 않는다.
• 생성자 주입
  • 필드 값에 'final'을 사용할 수 있으며 주입 받은 객체의 불변성을 보장한다.
  • 1회 호출을 보장하고 DI를 강제하며 순환 의존성을 검증할 수 있다.
  • 테스트 코드 작성이 쉽고 권장되는 방법이다.

public class MemberService {
   private final MemberRepository memberRepository;
   
   @Autowired	// 생성자가 하나일 때 생략 가능
   public MemberService(MemberRepository memberRepository){
      this.memberRepository = memberRepository
   }
}

 

 

3. 마치며

 다시금 공부하면서 IoC 를 잘 사용해야지 좋은 객체 지향 프로그래밍을 실현할 수 있다는 생각을 계속했다. 특히 SOLID 원칙 중 'OCP 개방 폐쇄 원칙'과 'DIP 의존 관계 역전 원칙'을 고수하기 위해서는 필수적이다.

기초적이고 기본적인 내용이지만 멀리 가기 위해서는 단단히 다져야한다.

차분히 멀리 가자.