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

황영빈님의 프로필 이미지
황영빈

작성한 질문수

스프링 핵심 원리 - 기본편

@Autowired 필드 명, @Qualifier, @Primary

Qualifier, 빈 이름 지정 등 OCP 위반

작성

·

467

0

학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.

1. 강의 내용과 관련된 질문을 남겨주세요.
2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.
(자주 하는 질문 링크: https://bit.ly/3fX6ygx)
3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.
(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)

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

[질문 내용]

강의를 듣다보니 궁금한 점이 생겨서 질문 남깁니다.

Interface에 대한 구현체가 여러개인 경우, 어떤 빈을 주입할지 결정하기 위해 @Qualifier를 이용하거나 빈 이름을 지정하는 방법등을 사용한다고 강의에 나오는데요.

이것을 보다보니 구현체를 바꾸려면 결국 사용하는 서비스 layer에서 관련 코드 (구현체를 바꾸는)를 수정해야 하는 거 같은데 이러면 OCP를 위반하게 되는 거 같아서요.


OCP 위반을 막으려면 AppConfig를 도입했을 때처럼 구현체를 설정하는 역할을 분리하고 수동 빈 등록으로 가야하는거 아닌가라는 생각이 들었는데 보통 실무에서는 어떻게 처리하는게 맞을까요??

구현체를 바꾸는 코드 변경정도는 tradeoff로 감수하는 편인가요 역할 분리하는 편인가요??

답변 2

0

안녕하세요. 황영빈님, 공식 서포터즈 David입니다.

트레이드오프로 생각합니다.

아래 글 답변을 참고해 주세요:)

https://www.inflearn.com/questions/160058

감사합니다.

0

안녕하세요, 인프런 AI 인턴이에요.

OCP(Open-Closed Principle)는 소프트웨어 개발의 원칙 중 하나입니다. OCP는 수정에는 닫혀 있고 확장에는 열려있어야 한다는 의미를 가지고 있습니다. 즉, 기존의 코드를 수정하지 않고도 새로운 기능을 추가할 수 있어야 합니다.

구현체를 변경하려면 사용하는 서비스 layer의 관련 코드를 수정해야 한다는 것은 맞습니다. 하지만 OCP를 위반하지 않으려면 구현체를 변경하는 부분을 인터페이스로 추상화하여 외부에서 구현체를 주입받도록 설계해야 합니다.

@Qualifier나 빈 이름을 지정하는 방법은 구현체를 주입받을 때 어떤 빈을 사용할지 결정하기 위한 방법입니다. 이를 통해 구현체를 변경하더라도 해당 빈의 이름이나 Qualifier만 수정하면 코드 변경을 최소화할 수 있습니다. 이렇게 인터페이스를 사용하여 외부에서 구현체를 주입받는 방식은 OCP를 준수하는 방법 중 하나입니다.

따라서, OCP를 위반하지 않으면서 구현체를 변경하려면 인터페이스를 사용하여 구현체를 주입받도록 설계해야 합니다. 이렇게 하면 구현체를 바꿀 때 관련된 코드 변경을 최소화할 수 있습니다.

더 자세한 내용이 필요하시면 구체적인 코드나 상황을 알려주시면 더 도움을 드릴 수 있을 것 같아요. 좋은 공부 되세요!

황영빈님의 프로필 이미지
황영빈

작성한 질문수

질문하기