묻고 답해요
141만명의 커뮤니티!! 함께 토론해봐요.
인프런 TOP Writers
-
미해결스프링 핵심 원리 - 기본편
Qualifier, 빈 이름 지정 등 OCP 위반
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? 예2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예[질문 내용]강의를 듣다보니 궁금한 점이 생겨서 질문 남깁니다.Interface에 대한 구현체가 여러개인 경우, 어떤 빈을 주입할지 결정하기 위해 @Qualifier를 이용하거나 빈 이름을 지정하는 방법등을 사용한다고 강의에 나오는데요.이것을 보다보니 구현체를 바꾸려면 결국 사용하는 서비스 layer에서 관련 코드 (구현체를 바꾸는)를 수정해야 하는 거 같은데 이러면 OCP를 위반하게 되는 거 같아서요.OCP 위반을 막으려면 AppConfig를 도입했을 때처럼 구현체를 설정하는 역할을 분리하고 수동 빈 등록으로 가야하는거 아닌가라는 생각이 들었는데 보통 실무에서는 어떻게 처리하는게 맞을까요??구현체를 바꾸는 코드 변경정도는 tradeoff로 감수하는 편인가요 역할 분리하는 편인가요??
-
미해결스프링 핵심 원리 - 기본편
OCP(Service와 ServiceImpl) 관련하여 질문드립니다.
안녕하세요. OCP 관련하여 질문드립니다. 개방-폐쇄 원칙(OCP, Open-Closed Principle) 을 지키기 위해 Service를 구현할때 인터페이스인 Service와 구현체인 ServiceImpl 로 보통 구현하는데, 이런 개발방식에 대해 의견이 좀 나뉘는 것 같아서요. 1. OCP 원칙을 준수해야하기때문에 사용해야한다. 2. 기존에 사용하던 방법이 관례처럼 남아있는 것이다. 굳이 그렇게 구현해야하는지 필요성을 못느끼겠다. 이렇게 두가지로 나뉘는데 구글에서 찾아보면 2번의견이 좀더 많아서 개인프로젝트를 진행중에 의문점이 들어서 질문드립니다~!
-
해결됨스프링 핵심 원리 - 기본편
할인 정책을 동시에 적용하고 싶은 경우 AppConfig 설정 방법
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예)[질문 내용] 안녕하세요 객체지향 개발에 관심이 생겨 공부중인 개발자 입니다. 좋은 강의 잘 듣고 있습니다. 한번에 하나의 할인 정책을 적용하는 경우는 AppConfig에서 지정을 해주면 되는데 만약 동시에 두 개 이상의 할인 정책을 적용하는 경우 어떤 방법으로 구현하면 좋을지 궁금해서 질문드립니다. 1. 현재 적용하고 있는 할인 정책이 하나인 경우 아래와 같이 AppConfig에서 제어흐름을 담당하면서 어떤 할인 정책을 적용할지 결정을 한다는 점은 이해했습니다. public DiscountPolicy discountPolicy() { // return new FixDiscountPolicy(); return new RateDiscountPolicy(); } 2. 할인 정책을 모두(정액, 정률) 사용하고 싶은 경우 예를 들어 할인 정책을 적용할 수 있는 쿠폰이 정액, 정률 두 개가 동시에 존재한다고 했을 때 클라이언트의 변경 없이(OCP) 할인정책을 적용하고 싶다면 AppConfig 에서 `discountPolicy()` 메소드를 호출할 때 정률 할인 쿠폰인 경우 `new RateDiscountPolicy()`를 리턴해야하고 정액 할인 쿠폰인 경우 `new FixDiscountPolicy()`를 리턴해줘야 합니다. 2-1. AppConfig 를 인터페이스로 변경하고 구현체를 별도로 생성 public class FixDiscountAppConfig implements AppConfig { … } public class RateDiscountAppConfig implements AppConfig { … } // OrderApp AppConfig appConfig; if (“정률할인 쿠폰”) { appConfig = new RateDiscountAppConfig(); } else If (“정액할인 쿠폰”) { appConfig = new FixDiscountAppConfig(); } AppConfig appConfig = new AppConfig(); MemberService memberService = appConfig.memberService(); OrderService orderService = appConfig.orderService(); 2.2 AppConfig 내 discountPolicy 메소드 호출 시 파라미터를 넘겨 구분 public DiscountPolicy discountPolicy(String 할인정책) { if (“정액”.equals(할인정책)) { return new FixDiscountPolicy(); } else { return new RateDiscountPolicy(); } } 한번에 하나의 정책을 적용하는 것보단 동시에 여러 정책을 적용하는 경우가 더 많을 것 같다고 생각이 들었습니다. 이 경우에는 어떤 방식으로 구현하는게 좋은 객체 지향원칙을 지키며 구현하는 것일지 조언을 구하고자 합니다.
-
미해결스프링 핵심 원리 - 기본편
@autowired 필드명, @qualifier 강의에서 OCP를 위반하는 것이 아닌지에 대해 질문이 있습니다
안녕하세요. 좋은 강의 감사드립니다. 다름이 아니라 @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를 위반하는 것인지 궁금합니다. 또한 만약 위반이 아니라면 왜 위반이 아닌지, 위반이라면 또 다른 해결책이 있는지 궁금합니다. 항상 좋은 강의, 명쾌한 강의, 속이 시원한 강의 해주셔서 너무나 감사드립니다. 강의 들으면서 속이 정말 뻥 뚫리는 느낌을 많이 받았습니다.