학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용]아래 코드처럼 한 클래스 내 생성자가 2개 이상인 경우, @Autowired를 주입하지 않으면 의존관계 주입이 이뤄지지 않나요???강의 내용에선 생성자가 1개인 경우 @Autowired를 생략해도 의존관계 주입이 자동으로 이뤄진다했는데, 2개 이상인 경우에도 되는 것 같아서요!@Component public class MyClass { private DependencyA dependencyA; private DependencyB dependencyB; public MyClass(DependencyA dependencyA) { this.dependencyA = dependencyA; } public MyClass(DependencyA dependencyA, DependencyB dependencyB) { this.dependencyA = dependencyA; this.dependencyB = dependencyB; } }

학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오) 예2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 예3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) 예[질문 내용]이 질문을 주변 사람에게 해봤더니 @Autowired는 의존성 주입과 관련된 부분이라 자동이든 수동이든 상관없이 @Autowired를 사용한다는 얘기를 들어서요..하지만 수동일땐 @Autowired를 사용안하던 것 같은데... 수동일 때도 @Autowired를 쓰긴 쓰나요..?

안녕하세요, 1년차 웹개발자로 일하고있는 영한님 제자입니다. 역할과 구현체에 대한 부분이 객체지향에서 가장 중요한 것 같은데 제가 하는 업무에서는 @Autowired로 퉁쳐서 하나의 역할에 하나의 구현체만 묶는? 경우가 많은 것 같아요.  이게 웹개발 SI 업계의 특징인지 아님 제가 잘못 코딩하고있는 건 지 궁금합니다. 게시판을 만들 때 제가 본 대부분의 코드는 하나의 컨트롤러에서 여러개의 Interface를 @Autowired하는 경우를 많이 봤습니다. 글 게시판, 사진 게시판, 익명 게시판 등 여러개의 게시판이 있다면 그 여러가지 게시판의 기능의 최소공배수를 준비해두거나(영한님 강의 중 자동차 I/F) 각 게시판 별 I/F가 하나씩 생기는(영한님 강의 중 소나타I/F, 그랜져I/F, 테슬라I/F) 경우를 많이 봐왔어요. 그러다 보니 객체지향 언어를 다루고 있으면서도 이게 객체지향인가? 싶고 영한님 강의를 볼때 ?? 내가 보던 코드에 저걸 어떻게 써먹지? 싶었거든요. 그래서 든 생각이  위와 같은 게시판을 만든다고 했을 때, 게시판 관리 I/F(게시글 조회 I/F, 게시글 상세보기 I/F,  게시글 작성 I/F)등을 만들어 두고 각각 익명 게시글 조회 구현체, 사진게시글 조회 구현체, 이런식으로 만들어두는 것이 바람직한 객체지향 설계인가? 하는 궁금증이 생겨서 확인 차 글을 남깁니다. 질문이 두서없지만 답변 미리 감사드립니다.

안녕하세요. 좋은 강의 감사드립니다. 다름이 아니라 @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를 위반하는 것인지 궁금합니다. 또한 만약 위반이 아니라면 왜 위반이 아닌지, 위반이라면 또 다른 해결책이 있는지 궁금합니다.  항상 좋은 강의, 명쾌한 강의, 속이 시원한 강의 해주셔서 너무나 감사드립니다. 강의 들으면서 속이 정말 뻥 뚫리는 느낌을 많이 받았습니다.