DI

차노·2023년 11월 9일
0
post-custom-banner

Dependency Injection (의존관계주입)
A가 B를 의존할 때, 의존 대상 B가 변하면 A도 영향을 받는다. 예를 들어, B의 기능이 추가 또는 변경이 될 때 그 영향이 A에 미친다. 예를 들어 햄버가 가게 요리사는 햄버거 레시피에 의존한다. 햄버거 레시피가 변화하게 되었을 때 요리사는 햄버거 만드는 방법을 바꿔야 한다.레시피의 변화가 요리사의 행위에 영향을 미친게 되는 거고 요리사는 레시피에 의존한다라고 말할 수 있다.

의존관계를 인터페이스로 추상화하기

더 다양한 버거레시피의 의존을 받기 위해서는 인터페이스로 추상화해야 한다. 의존관계를 인터페이스로 추상화하게 되면, 더 다양한 의존 관계를 맺을 수 있고, 실제 구현 클래스와의 관계가 느슨해지고, 결합도가 낮아진다.

지금까지의 구현은 BurgerChef 내부적으로 의존관계인 BurgerRecipe가 어떤 값을 가질지 직접 정하고 있다. 만약 어떠한 버거레시피(의존 대상)를 만들지를 버거 가게 사장님이 정하는 상황을 상상해볼 수 있다. 즉, 버거 셰프가 의존하고 있는 버거 레시피를 외부(사장님)에서 결정하고 주입하는 것이다. 이처럼 그 의존관계를 외부에서 결정하고 주입하는 것이 DI이다.

  • 클래스 모델이나 코드에서는 런타임 시점의 의존관계가 드러나지 않는다. 그러기 위해서는 인터페이스만 의존하고 있어야 한다.

DI 구현 방법

DI는 의존관계를 외부에서 결정하는 것이기 때문에 클래스 변수를 결정하는 방법들이 곧 DI를 구현하는 방법이다. 런타임 시점의 의존관계를 외부에서 주입하여 DI 구현이 완성된다.

  • 생성자 이용
  • 메소드 이용

장점

  1. 의존성이 줄어든다.

    의존한다는 것은 변화에 취약하다. (대상이 변화하였을 때 이에 맞게 수정해야 한다.) DI로 구현하게 되었을 때 주입받는 대상이 변하더라도 그 구현 자체를 수정할 일이 없거나 줄어들게 된다.

  2. 재사용성이 높은 코드가 된다.

    기존의 버거셰프 내부에서만 사용되었던 버거레시피를 별도로 구부하여 구현하게 되면 다른 클래스에서 재사용할 수 있다.

  3. 테스트하기 좋은 코드가 된다.

    버거 레시피의 테스트를 버거 셰프 테스트와 분리하여 진행할 수 있다.

  4. 가독성이 높아진다.

    버거레시피의 기능들을 별도로 분리하게 되어 자연스레 가독성이 높아진다.

정리

DI는 객체가 의존하는 또 다른 객체를 외부에서 선언하고 이를 주입받아 사용하는 것이다.

참고

post-custom-banner

0개의 댓글