의존관계주입 OCP, DIP

[질문 템플릿]
1. 강의 내용과 관련된 질문인가요? 예
2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예
3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예

[질문 내용]

자동의존관계 주입시 중복되는 빈이 2개일때

파라미터 이름, Qualifier 를 쓴다고 하는데 쓰는거는 이해가 가는데 들으면거 의문이 든게 만약 이런걸 붙여서 Impl 코드를 수정해야된다면 예를들어 파라미터이름을 rateDiscountpolicy 로 쓰다가 fixDiscountPolicy로 바꾼다면 예전에 배운 DIP와 OCP 를 지켜지는게 맞는가 싶더라고요, 만약 중복을 분리하기위해 그렇게한다면 new RateDiscountPolicy 에서 new FixDiscountPolicy 로 바꾸는것과 큰차이가 잇을까였습니다.

결국 구현체를 바꾸고싶을때 직접적으로 코드를 수정해야된다면 이러한 규칙이 잘맞는지 굳이 써야할이유가 있는지 궁금합니다

안녕하세요, 인프런 AI 인턴입니다. 김태언님.

스프링 환경에서 의존성을 관리할 때, 하나의 인터페이스를 여러 구현체로 대체할 수 있는 경우, @Qualifier나 파라미터 이름 매칭을 통해 특정 구현체를 선택하는 방법에 대해 질문 주셨네요. 이러한 접근 방법은 OCP(개방-폐쇄 원칙)와 DIP(의존성 역전 원칙)의 관점에서 보았을 때 약간의 혼란을 줄 수 있습니다.

OCP와 DIP: 이 두 원칙은 코드가 변경 없이 새로운 기능을 추가할 수 있어야 하고, 고수준 모듈이 저수준 모듈에 의존하지 않도록 하기 위해 인터페이스에 의존해야 함을 뜻합니다. @Qualifier나 파라미터 이름 매칭은 특정 상황에서 인터페이스보다 구현체에 더 가깝게 의존하는 느낌을 줄 수 있습니다.
코드 변경의 필요성: 사용자가 구현체를 변경하기 위해 코드내에서 파라미터 이름을 수정해야 한다는 점은 OCP를 엄격하게 적용한다고 볼 수는 없습니다. 하지만 이는 스프링의 DI 컨테이너가 제공하는 편의성 때문에 발생하는 트레이드 오프라고 볼 수 있습니다. 즉, 실제 개발 환경에서 이 방법이 변경의 폭을 줄여주는 편리한 옵션을 제공하기도 합니다.
왜 쓰는가?: @Qualifier나 @Primary 같은 어노테이션은 특정 환경에서 복잡한 설정을 단순화할 수 있으며, 다양성과 유연성을 제공합니다. 특정 시점에 기본값을 지정하거나, 특정한 경우에 한정된 의존성을 자연스럽게 주입할 수 있습니다.

아래 링크들은 이와 관련한 내용으로, 더 깊은 이해를 돕기 위해 참고하시면 좋겠습니다:
- @Qualifier, @Primary가 OCP, DIP를 위반하지 않나요? - Inflearn
- @Qualifier와 @Primary를 사용하는 것이 OCP, DIP 원칙을 위반하는지에 대한 논의를 통해 이 문제에 대한 명확한 시각을 제공하는 답변입니다.
- @Autowired 필드 명 매칭시에도 DIP위배 - Inflearn
- @Autowired의 필드 명 매칭을 통한 의존성 주입이 DIP를 위반하는지에 대해 다루고 있는 답변입니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

인프런 커뮤니티 질문&답변