질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예)[질문 내용]SOLID 원칙 중에서 SRP(단일 책임 원칙)이 하나의 책임만 주고 변경에 대해 다른 객체들에게 영향을 미치지 않는다라고 이해를 했습니다.   그리고 ISP(인터페이스 분리 원칙)는 클라이언트가 의존을 하지 않도록 중간에 인터페이스를 두어서 분리를 시킨다라고 이해를 했습니다.   그런데 이 두개가 책임을 나눈다라는 같은 문제에 대해 제시하는 해결책이라고 생각이 드는데 구현 시에 어느 원칙을 준수하는게 더 우선시 되는 건가요?

안녕하세요. 좋은 강의 감사드립니다. 다름이 아니라 @Autowired 필드명, @Qualifier, @Primary 강의에서 조회 된 빈이 2개 이상일 때 @Autowired 필드명 이나 @Qualifier, @Primary 등을 사용하여 해결한다고 배웠습니다. 궁금한 점을 먼저 써보면, 위와 같은 해결 방법을 사용 시에 기존 구현체 클래스에 직접적인 수정이 일어나는 것에 대해서  1.OCP를 위반하게 되는 것일까요? 2.만약 위반이 아니라면 왜 위반이 아닌지 궁금합니다. 3.위반이라면 또 다른 해결책이 있는지 궁금합니다. 자세한 상황은 이렇습니다. 강의에서 OrderServiceImpl.class 에서 생성자 주입을 통해 discountPolicy에 두 개의 빈이 찾아져버리므로, 특정 빈을 찾을 수 있도록 인자의 파라미터 이름을 수정해야했습니다. (@Autowired 필드명 방식) @Autowired public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) { this.memberRepository = memberRepository; this.discountPolicy = discountPolicy; } <OrderServiceImpl.class 수정 전> @Autowired public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy rateDiscountPolicy) { this.memberRepository = memberRepository; this.discountPolicy = rateDiscountPolicy; } <OrderServiceImpl.class 수정 후> 이것이 개방-폐쇠 원칙을 못지킨 것이 아닌가 하는 의문이 들었습니다. 이전에 같은 문제로 Component Scan 을 사용하지 않고 AppConfig.class에서 직접 수동으로 Bean을 생성하여 등록하는 과정에선 겹치는 빈이 있을 경우 AppConfig.class 내에서 해결 할 수 있었습니다.. 코드로 보자면 다음과 같습니다. (애초에 수동으로 빈을 등록하므로 애초에 두 개의 빈이 올라오지 않도록 빈을 안올려도 되며, 만약 두 개의 빈을 둘 다 올린다해도 아래와 같이 작성하면 의존성 주입 시 두 개의 빈 찾아져 오류가 생기는 일은 없을 것 같다고 생각합니다.) @Bean public DiscountPolicy discountPolicy() { //return new FixDiscountPolicy(); return new RateDiscountPolicy(); } 하지만 Component Scan, Component, Autowired를 사용할 땐 AppConfig.class에서 하던 것처럼 할 수는 없고, 직접 Impl 클래스에 변경을 해야하거나 @Quilifier 혹은 @Primary 어노테이션을 붙이기 위해 구현체의 클래스를 찾아가서 수정해줘야하는 것 같습니다. 바로 이 부분에 대해서, OCP를 위반하는 것인지 궁금합니다. 또한 만약 위반이 아니라면 왜 위반이 아닌지, 위반이라면 또 다른 해결책이 있는지 궁금합니다.  항상 좋은 강의, 명쾌한 강의, 속이 시원한 강의 해주셔서 너무나 감사드립니다. 강의 들으면서 속이 정말 뻥 뚫리는 느낌을 많이 받았습니다.