묻고 답해요
130만명의 커뮤니티!! 함께 토론해봐요.
인프런 TOP Writers
-
미해결스프링 핵심 원리 - 기본편
한 클래스 내 생성자가 2개 이상이면 @Autowired 붙여야만 의존관계 주입이 이뤄지나요??
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.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; } }
-
해결됨스프링 핵심 원리 - 기본편
수동SpringBean등록 : @Bean을 사용, @Autowired사용X , 자동SpringBean등록 : @Component, @Autowired사용 이렇게가 맞을까요??
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오) 예2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 예3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) 예[질문 내용]이 질문을 주변 사람에게 해봤더니 @Autowired는 의존성 주입과 관련된 부분이라 자동이든 수동이든 상관없이 @Autowired를 사용한다는 얘기를 들어서요..하지만 수동일땐 @Autowired를 사용안하던 것 같은데... 수동일 때도 @Autowired를 쓰긴 쓰나요..?
-
해결됨스프링 핵심 원리 - 기본편
@Autowired를 사용하는 setter가 AppConfig를 설정 정보로 갖는 test 클래스에서도 실행 가능한 이유
안녕하세요! 김영한 선생님의 스프링 핵심 원리 강의를 수강하고 있는 학생입니다:)다름 아니라 setter 주입의 예제 코드와 관련하여 궁금한 점이 생겨서 질문을 남기게 되었습니다.강의 13:26에 나와있는 코드와 동일하게 setter와 생성자에 화면 출력 기능을 추가하였습니다. 그 결과, AutoAppConfig.class를 설정 정보로 하는 test 클래스를 실행하면 설명해주신 내용과 같이 생성자를 통한 의존 관계 주입이 먼저 일어나고 setter를 통한 의존 관계 주입이 나중에 일어남을 확인할 수 있었습니다.더 나아가 AutoAppConfig.class가 아닌 AppConfig.class를 설정 정보로 하는 test 클래스를 실행하면 콘솔 화면에 어떤 내용이 출력될지 호기심이 생겨 test.java.hello.core.beanfind 패키지에 위치한 ApplicationContextBasicFindTest 클래스를 실행하였습니다. 실행 전에 저는 orderService라는 이름의 스프링 빈이 등록되는 과정에서 orderServiceImpl() 생성자가 호출되기 때문에 System.out.println("1. OrderServiceImpl.OrderServiceImp"); 코드가 실행될 것이라 예상하였습니다.또한,(1) AppConfig.class엔 setMemberRepository()와 setDiscountPolicy()를 호출하는 코드가 없고 (2) AppConfig.class는 @ComponentScan를 사용하지 않기 때문에 setMemberRepository()와 setDiscountPolicy()가 @Autowired를 사용하고 있더라도 의존 관계를 자동으로 주입할 수 없어 해당 메소드(setter) 내부에 기재되어있는 System.out.println("memberRepository = " + memberRepository); 코드와 System.out.println("discountPolicy = " + discountPolicy); 코드는 실행되지 않을 거라 예상했습니다.하지만 저의 예상과는 다르게 setMemberRepository()와 setDiscountPolicy()가 모두 실행되었고 제가 어느 부분에서 잘못 생각하고 있는지 도움을 구하고자 질문을 남기게 되었습니다.
-
미해결스프링 입문 - 코드로 배우는 스프링 부트, 웹 MVC, DB 접근 기술
@Autowired 관련 질문
강의(자바코드로 직접 스프링 빈 등록하기)에서 마지막 부분에 @Autowired를 통한 DI는 스프링이 관리하는 객체에서만 동작한다는 설명 해주실때 @Autowired가 먹질않는다는 뜻을 잘모르겠습니다 그래서 @Autowired 를 사용하지 않으면 어떻게 되는건지도 궁금합니다..(@Autowired 의 의미? 뜻 을 잘 모르겠습니다) 생성자 주입 로직만 있으면 의존관계 설정 (DI) 완료되는게 아닌건가요?? @Autowired 를 사용하지 않으면 memberService 클래스 내에서 repository를 사용하려면 예전에 하던 new 로 생성해야 하는거랑 똑같게 되는 건가요??
-
미해결실전! 스프링 부트와 JPA 활용1 - 웹 애플리케이션 개발
@Autowired 를 통하여 여러개의 Repository 를 하나의 메소드에서 처리해도되나요?
안녕하세요, 강의잘보고있습니다. 여러가지 lombok 이나 다른 편의라이브러리를 사용하는것도 좋지만 아직은 구조잡기가 우선이라고 생각하여 최대한 필수구조를 잡아가며 짜는연습중인데 강의중에 Requirment... Annotation 을 사용하지않고 아래 방법대로 @Autowired 가 되어도 문제가없는지 질문드립니다. @Service@Transactional(readOnly = true)public class OrderService { private final MemberRepository memberRepository; private final OrderRepository orderRepository; private final ItemRepository itemRepository; @Autowired public OrderService(MemberRepository a, OrderRepository b, ItemRepository c) { this.memberRepository = a; this.orderRepository = b; this.itemRepository = c; }}
-
미해결스프링 핵심 원리 - 기본편
Autowired 의 필드명과 Qualifier 를 사용하는 것 질문드립니다.
Autowired 에서 필드명, 파라미터명에 의존하는 것과 Qualifier 를 사용하여 서비스를 조작하는 것은 DIP 에 어긋나는 것으로 보입니다. 혹시 이 생각이 다소 옳지 못다하다면 어느 부분을 수정해야하는지 말씀부탁드리고 위의 생각이 맞다면 어떻게 저 부분을 받아들여야 하는지 말씀부탁드립니다.
-
미해결스프링 핵심 원리 - 기본편
@Autowired를 보다보니 질문이 있습니다.
안녕하세요, 1년차 웹개발자로 일하고있는 영한님 제자입니다. 역할과 구현체에 대한 부분이 객체지향에서 가장 중요한 것 같은데 제가 하는 업무에서는 @Autowired로 퉁쳐서 하나의 역할에 하나의 구현체만 묶는? 경우가 많은 것 같아요. 이게 웹개발 SI 업계의 특징인지 아님 제가 잘못 코딩하고있는 건 지 궁금합니다. 게시판을 만들 때 제가 본 대부분의 코드는 하나의 컨트롤러에서 여러개의 Interface를 @Autowired하는 경우를 많이 봤습니다. 글 게시판, 사진 게시판, 익명 게시판 등 여러개의 게시판이 있다면 그 여러가지 게시판의 기능의 최소공배수를 준비해두거나(영한님 강의 중 자동차 I/F) 각 게시판 별 I/F가 하나씩 생기는(영한님 강의 중 소나타I/F, 그랜져I/F, 테슬라I/F) 경우를 많이 봐왔어요. 그러다 보니 객체지향 언어를 다루고 있으면서도 이게 객체지향인가? 싶고 영한님 강의를 볼때 ?? 내가 보던 코드에 저걸 어떻게 써먹지? 싶었거든요. 그래서 든 생각이 위와 같은 게시판을 만든다고 했을 때, 게시판 관리 I/F(게시글 조회 I/F, 게시글 상세보기 I/F, 게시글 작성 I/F)등을 만들어 두고 각각 익명 게시글 조회 구현체, 사진게시글 조회 구현체, 이런식으로 만들어두는 것이 바람직한 객체지향 설계인가? 하는 궁금증이 생겨서 확인 차 글을 남깁니다. 질문이 두서없지만 답변 미리 감사드립니다.
-
미해결스프링 입문 - 코드로 배우는 스프링 부트, 웹 MVC, DB 접근 기술
Autowired 대신, AllargsConstructor 사용 관련
Autowired 대신, AllargsConstructor 사용하면 안되나요? 잘 동작하기는 하는데 어떤게 더 좋은 방식인지 모르겠어요
-
미해결스프링 핵심 원리 - 기본편
@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를 위반하는 것인지 궁금합니다. 또한 만약 위반이 아니라면 왜 위반이 아닌지, 위반이라면 또 다른 해결책이 있는지 궁금합니다. 항상 좋은 강의, 명쾌한 강의, 속이 시원한 강의 해주셔서 너무나 감사드립니다. 강의 들으면서 속이 정말 뻥 뚫리는 느낌을 많이 받았습니다.