Spring DI 제대로 이해하고 있나?

이전 글: https://koolreview.tistory.com/121

Spring DI 방법론

 예전에 DI에 대해 정리했었다. 그런데 회사 내에서 인터페이스를 사용하지 않고 있었다. 실제 Class만 이용해서 구현하고 있었다. 그런 이유는 하나의 인터페이스에 하나의 구현체만 존재하는 일종의 1대 1 구조로 되어 있는 경우가 많았기 때문이었다. 

 인터페이스를 쓰는 경우에도, 인터페이스가 없는 경우에도 의아스러움은 사라지지 않았다. 형식화되어 있는 것이 프레임워크이긴 하지만... 이게 맞을까? 진짜 DI가 무엇일까? 그냥 의존성을 주입한다는 건가? 그런 생각을 계속하게 되고 찝찝함은 남아있었다.

 인터페이스를 왜 쓸까? 설계서를 작성하는 것과 같은데, 구현체를 바꿔 쓰면서 유연성을 가지기 위함이 아닐까? 그런 유연성을 고민하다보면 if문으로 가능한 데 굳이? 인터페이스를 나눠서 써야하지? 이런 생각을 하게 된다.

다음과 같은 예를 생각해볼까?

 당신은 이벤트 신청 Api, 이벤트 참가 Api를 개발한다고 생각해보자. 그런데 이벤트란 여러 종류가 존재하지 않은가? 단순히 박스 이벤트, 룰렛 등 심지어 참가 방식도 기간 내 참가, 매일 참가 등 많다. 그런 모든 이벤트를 하나의 EventService로 만든다고 생각해보자.

 아마 당신은 Http Call 파라미터로 이벤트의 종류를 보내주지 않을까? 그리고 그 종류에 따라 함수를 따로 쓰고 있지 않을까? 사실 그래도 상관은 없을 것 같긴 한데... 함수가 복잡해지면.. 아니 처음엔 4개에 였던 파라미터가 5개로 늘어나고, 너무 다른 로직을 가지게 된다면 다른 이름의 함수를 만들거나 하지 않을까? 하나의 서비스에 너무 많은 범용성을 가지고 있는 것이 아닐까?

 구글, 페이스북, 카카오, 네이버 등 Oauth 로그인 개발에는 전략 패턴이 들어가서 각 프로바이더에 맞는 로직이 따로 각 Class마다 들어간다. 위 예시인 EventService도 그런 것이 아닐까?

 그런데 결국 본질은 Event이기 때문에 DB 적재 함수를 따로 만들어 동일하게 사용할 수도 있다. 그런 경우 모든 구현체에 다 구현해줘야 하나? 그런 경우 인터페이스 Default 메소드가 떠오르지 않을까? 그런데 이 Deafult 메소드에서는 Bean에 접근할 수가 없어서 불편한 경우가 발생한다.

이런 경우에는 어떻게 해야할까? 그리고 여러 구현체를 가지고 있는 경우 어떻게 구현체를 불러서 써야할까? 그리고 구현체는 여러 개지만 운영에서만 사용하는 구현체가 1개라면 어떻게 개발해야 할까?

아니 그래서 유연한가? 의존성 주입은 유연함이고 인터페이스는 SOLID의 D인 DIP 그런 의존관계 역전 법칙을 잘 사용하고 있는 것인가?

시간 날 때 다음 글에서 구체적인 예시를 하나씩 적어봐야겠다.