cheese10yun / blog-comment

0 stars 0 forks source link

Spring 예제로 보는 SOLID DIP - Yun Blog | 기술 블로그 #41

Open utterances-bot opened 3 years ago

utterances-bot commented 3 years ago

Spring 예제로 보는 SOLID DIP - Yun Blog | 기술 블로그

Yun Blog | 기술 블로그

https://cheese10yun.github.io/spring-solid-dip/

limwoobin commented 3 years ago

감사합니다 잘읽었습니다

yoonjoynow commented 2 years ago

안녕하세요! 좋은 글 항상 잘 읽고 있습니다. 글을 읽으면서 제가 구현할 때 맞닥드렸던 고민과 겹치는 부분이 있어 질문글 남깁니다.

작성자님 글의 요지는 상위 수준의 모듈은 하위 수준의 모듈에 의존하면 안 된다, 즉 구현이 아닌 행동에 의존하라 라고 느꼈습니다. 그래서 CardPaymentService 같은 경우에는 여러 카드사의 CardPayment의 구현 방식이 다르므로 인터페이스 추상체를 뽑아내어서 PaymentController가 이 추상체를 대신 의존하게 하구요. 여기서 궁금한 것이 PaymentController가 구현체가 아닌 추상체를 의존하게 되면, 언제 어떤 구현체를 사용해야하는지 어떻게 알 수 있을까요??

예를 들면 PaymentController에 각 카드사 별로 카드결제서비스 api를 제공해주고, CardPaymentService 타입으로 빈을 주입받으려고 한다면 CardPaymentService 타입의 빈이 여러개라 에러가 날 텐데 말이죠.

그래서 제가 생각한 방법은 카드사 별로 PaymentController를 나누어서 각 컨트롤러에서 NhCardPaymentService, TossCardPaymentService 등 인터페이스 대신 구현체를 주입받는 방식과 PaymentController 안에서 모든 CardPaymentService의 구현체를 주입받는 방식이 떠오르는데, 작성자님은 이 문제를 어떻게 해결하시고 계실까요?