영한선생님 궁금한게 있습니다. MemberRepository는 메모리에도 저장할 수 있고, 디비에도 저장할 수 있기에 인터페이스로 구현 후에 구체화 하여 클래스를 구현하는 것 까지는 이해가 되는데 MemberService는 왜 따로 인터페이스를 구현했고 , MemberserviceImpl이라는 구현 클래스를 만들었는지 알려 주시면 감사하겠습니다.

안녕하세요 MVC 강의를 보다가 복습하러  왔는데 오늘 하루종일 검색하고 찾아봐도 이해가 가지 않아서 질문드립니다  핵심원리 강의에서 ApplicationContext가 스프링 컨테이너라고 설명을 해 주셨고 이후 강의에서  ApplicationContext ac =new AnnotationConfigApplicationContext(클래스명); 이 문장을 사용해 스프링 컨테이너 생성 후 매개변수값의 클래스에 있는 에노테이션 기반의 빈을 등록하면 싱글톤이나 의존관계 주입 관리를 할 수 있는것으로 이해하였는데요, 앞선 입문 강의나 이후 mvc강의에서는 해당 스프링 컨테이너 생성문장 없이 @Component나 Controller등의 에노테이션만 붙이면 스프링 컨테이너 없이 빈이 등록되는데 여기서 이해가 되지 않습니다.  톰캣 서버의 서블릿 컨테이너가 해당 역할을 하는것인가요..? 어디서 잘못 이해한것인지 모르겠습니다 ㅠㅠ..

안녕하세요 영한님! 공부와는 상관없는 내용이긴 하나 궁금해서 여쭤봅니다. 다이어그램은 어떤 툴을 사용해서 그리시나요?? 

안녕하세요 Jpa부터 시작해서 강의 잘보고있습니당! 좋은 강의 항상 감사드려요! 다름이아니라 우리나라 si기업에서는 대부분 spring 부트를 사용하지 않고 spring legacy 프로젝트로 일을 한다고 하더라고요... 저는 spring boot 가 너무 좋고 spring 의 다양한 기능들을 사용하기 위해서는 spring boot 가 최적이란 것또한 이해 하였는데 왜 우리나라 많은 si 에서는 왜 서버띄우기도 느린 외장 톰캣을 쓰며, 복잡한 xml 설정들을 다 잡아줘야하는 spring legacy를 사용하는지 이해가 안되더라고요.. 혹시 spring boot 가  spring legacy 에 비해  단점이 존재할까요? 예를 들면 혹시  성능상 어떤것이 안돌아간다던가... 큰 규모의 프로젝트에서는  한계가 있다거나...혹시 spring boot 의 단점이 있나요?

아랫분들도 비슷한 질문을 해주셨는데, 그에 대한 답변이 제대로 이해가 안가서 다시한번 질문드립니다. ==============>질문을 드리는 과정에서 제가 이해한 내용이 있는데 이해한 내용이 맞는지 확인부탁드립니다! 제가 지금까지 수강들은 내용을 적자면 @Configuration 을 통해 컨테이너에 저장되면 같은 클래스에 대해 싱글톤이 유지 된다고 이해하였습니다. 그런데 제가 예제를 다시 돌아보면서 의문이 생겨 질문 기존 AppConfig에서 @Configuration을 주석을 하였습니다. //@Configurationpublic class AppConfig { @Bean public MemberService memberService() { System.out.println("call AppConfig.memberService"); return new MemberServiceImpl(memberRepository()); } @Bean public OrderService orderService() { System.out.println("call AppConfig.orderService"); return new OrderServiceImpl(memberRepository(), discountPolicy()); } @Bean public MemberRepository memberRepository() { System.out.println("call AppConfig.memberRepository"); return new MemoryMemberRepository(); } @Bean public DiscountPolicy discountPolicy() { return new RateDiscountPolicy(); }} 이후 테스트 코드에서 두개의 객체를 생성해 값을 확인해보았습니다. #1번테스트 @Test void springContainer(){ ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class); //1. 조회 : 호출할 때 마다 객체 생성 MemberServiceImpl memberService1 = ac.getBean("memberService", MemberServiceImpl.class); //2. 조회 : 호출할 때 마다 객체 생성 MemberServiceImpl memberService2 = ac.getBean("memberService",MemberServiceImpl.class); //참조값이 같은 것 확인 System.out.println("memberService1 = " + memberService1); System.out.println("memberService2 = " + memberService2);// assertThat(memberService1).isSameAs(memberService2); } 테스트 결과 두 개의 객체 memberService1과 memberService2의 참조값이 같다는걸 확인했습니다. 저는 이 결과를 보고 @Configuration이 없이 싱글톤이 유지되어 의문이 생겼습니다. @Configuration을 여전히 주석한 상태로 다른 테스트인  #2번테스트 @Test void configurationTest(){ ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class); MemberServiceImpl memberService = ac.getBean("memberService", MemberServiceImpl.class); OrderServiceImpl orderService = ac.getBean("orderService", OrderServiceImpl.class); MemberRepository memberRepository = ac.getBean("memberRepository", MemberRepository.class); MemberRepository memberRepository1 = memberService.getMemberRepository(); MemberRepository memberRepository2 = orderService.getMemberRepository(); System.out.println("memberService -> memberRepository1 = " + memberRepository1); System.out.println("orderService -> memberRepository2 = " + memberRepository2); System.out.println("memberRepository = " + memberRepository);// assertThat(memberService.getMemberRepository()).isSameAs(memberRepository);// assertThat(orderService.getMemberRepository()).isSameAs(memberRepository); } 이 코드의 결과를 확인해보니 세개의 객체 memberRepository가 모두 다른 참조값을 가지고 있음을 확인했습니다. 그리고 다시 AppConfig.class에 @Configuration의 주석을 해제 후 같은 참조값을 가진것을 확인했습니다. 질문을 드리면서 제가 깨달은 내용은 #1번테스트와 #2번테스트 의 차이는 1번 테스트는 스프링컨테이너에 MemberService가 하나만 등록되었기 때문에 여러개를 생성해서 같은 참조값을 가지게 된거고 2번 테스트는 스프링컨테이너에 MemberRepository가 3가지의 객체로 저장되었기 때문에 3가지의 객체 모두 다른 참조값을 가지게 된거다. 따라서 @Configuration을 통해 스프링컨테이너에 MemberRepository를 싱글톤형태로 하나만 남게 된 것. 제가 이해한 내용이 맞나요? 제가 이해한 내용이 맞다면 제가 지금껏 잘못 생각한 내용은 @Configuration 이 없이 스프링컨테이너에  등록하게 되면 싱글톤 유지를 하지 못하는것은 맞는데 싱글톤의 범위(?)를 제가  잘못 이해하고 있었던 것 같습니다. 그냥 혼자 이해하고 말까라고 생각했다가 확인을 받고, 저랑 비슷하게 이해하셨던 분들이 있으신거 같아서 글 올립니다! 감사합니다!

안녕하세요. 질문드립니다. 강의를 내용의 예제를 확인해보면 @Target(ElementType.TYPE)@Retention(RetentionPolicy.RUNTIME)@Documentedpublic @interface MyExcludeCompnent {} 형태로 어노테이션 MyExcludeComponent를 생성하고 @MyExcludeComponentpublic class BeanB {} class BeanB가 어노테이션을 받았는데 @ComponentScan( includeFilters = @Filter(type = FilterType.ANNOTATION, classes = MyIncludeComponent.class), excludeFilters = @Filter(type = FilterType.ANNOTATION, classes = MyExcludeComponent.class)) MyExcludeComponent 를 exclude하고 ComponentScan을 하였는데 애초에 ComponentScan 대상에 @MyExcludeComponent 는 없지 않나요?  단순히 사용방법을 위해서 저렇게 진행하신건지 궁금합니다! 

lastIndexOf  2번째 parameter의 값이 0보다 작을 경우 무조건 -1을 반환한다는 것처럼 기술이 되어있어서 그런줄 알았는데 lastIndexOf도 indexOf처럼 두번째 parameter 값이 음수가 되면 0부터 검색한다는 개념으로 만약 value[0]에 1번째 parameter에 입력한 값이 존재 한다면 0으로 출력이 되는 부분이 있는 것 같습니다 이게 맞나요?

Client 에서 prototypeBean을 생성하고 의존관계를 주입하면, client 구현체가 prototypeBean의 메모리 주소를 가지고 있는 것으로 이해했는데, 그럼 ac.close()로 컨테이너를 내리면,  client 가 가리키던 prototypeBean 까지 메모리가 해제되나요? 아니면 링크만 끊겨서 메모리 어딘가에 떠다니나요..?

public class Order { private Long memberId; private String itemName; private int itemPrice; private int discountPrice; public Order(Long memberId, String itemName, int itemPrice, int discountPrice) { this.memberId = memberId; this.itemName = itemName; this.itemPrice = itemPrice; this.discountPrice = discountPrice;} 위에 private Long memberId; 이렇게 정의 하는데 굳이 생성자를 만들 필요가 왜 있는 건가요??

안녕하십니까 선생님 필터 부분 강의를 들으면서 궁금한 점이 생겨 질문드립니다. BeanA와 BeanB는 따로 @Component가  붙어있지 않습니다. 그래서 저는 혹시 만드신 MyExcludeComponent와 MyIncludeComponent에 붙어 있는 어노테이션 중에 @Component가 있을까해서 찾아보았는데 없었습니다. ComponentScan에서 사용하는 includeFilters에도 있나 했는데 없었습니다. 그렇다면 클래스에 따로 Component가 붙어있지 않을 때도(물론 붙어있으면 빈으로 등록되는 것은 알고 있습니다!), includeFilter를 사용하게 되면 스프링 빈으로 등록이 되는건가요?

안녕하세요. 강의 너무 잘 보고 있습니다. 감사합니다.@Configuration과 @ComponentScan과 관련해서 질문이 있습니다. 1. AutoAppConfig class에 @ComponentScan이 정의돼 있으면,  추가적으로 Bean정의를 해주는 게 아니라면@Configuration은 필요 없지 않나요?  2.  AppConfig에 @Configuration 어노테이션이 살아있으면 CoreApplication을 시작할 때, 이번에 새로 작성한 AutoAppConfig에서 빈을 등록하고 AppConfig에서 다시 한 번 Bean을 등록하면 Bean을 중복 등록하지 않나요?  3.  @Configuration의 기능이 @Configuration이 사용된 클래스에 정의된 Bean 전부를 Spring Container에 등록하는 걸로 이해했습니다. @Configuration만 사용하면 프로젝트 전 범위의 파일을 스캔하지만  여기서 @ComponentScan의 Fiter 기능을 추가하면 탐색 범위를 축소시킬 수 있는 건가요?

  앞서 강의에서 AppConfig파일을 만들고 의존성을 주입했던 이유는  - 기존의 자바 코드가 DIP를 위반 했고,  - 또한 OCP 역시 만족하지 못했기 때문이었습니다.  따라서 AppConfig파일은 기존의 코드를 전혀 건들지 않고도 새로운 구현체를 역활에 맞게 끼워넣을 수 있었습니다.  하지만 @ComponentScan과 @Component를 통해 자동으로 스프링빈을 등록하는 방식은 역활에 따른 구현을 갈아 끼울 때 또다시 코드를 '수정'해야합니다. 저의 생각으로는 이는 앞서 말했던 OCP를 위반하는 방식 같은데, 이러한 방식은 OCP를 위반해서라도 더 편하게 Bean을 관리하기 위함입니까? 아니면 뒷쪽 강의에서 이에대한 이야기가 추가적으로 언급이 되나요?

/**1. Qualifier 의 속성을 복사한다. */@Target({ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER, ElementType.TYPE, ElementType.ANNOTATION_TYPE})@Retention(RetentionPolicy.RUNTIME)@Inherited@Documented@Qualifier("mainDiscountPolicy")public @interface MainDiscountPolicy {} 안녕하세요 선생님 수업질문이 있습니다! @Qualifier 타입체크 문제를 해결하기 위해 위 코드처럼 빈을 따로 생성하면서 Qualifier 위에 @Target @Retention,, 등등의 속성을 가져왔는데 그럴필요 없이 @Qualifier만 명시해도 그 안에 속성을 자동으로 데려오는게 아닌지 궁금합니다. 

안녕하세요. 강의 열심히 잘 듣고있습니다. 스프링입문편 다 듣고 스프링기본 반정도 수강했는데 처음 들어서는 이해가 잘 안되다보니 한강의 듣고 강의 내용 복기하고 또 다음 강의듣고 내용 복기하고 이런 식으로 반복이 되니 강의 듣는 시간이 2~3배 길어지게 되었습니다. 그래서 새롭게 계획을 세워봤는데 일단 강의를 들으며 모르는 부분은 체크하고 넘어간 후 완강을 한 다음에 모르는 부분을 공부하고 책을 읽고 다시 강의를 들어보는거로 계획을 세웠습니다 혹시 영한님께서 추천해주시는 다른 공부 방법이 있을까요? 사람마다 맞는 방식이 다르다고 하지만 그래도 저보다 선배님으로써 가장 효율적인 방법을 알고싶습니다! 책은 토비의 스프링3.1 , 이것이 자바다, 이펙티브 자바 이렇게 3권 읽고있습니다.

- 학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! - 먼저 유사한 질문이 있었는지 검색해보세요. - 서로 예의를 지키며 존중하는 문화를 만들어가요. - 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 회원 저장소와 할인 정책은 바뀔 수 있기 때문에 역할과 구현체로 나뉘는게 이해가 되었는데 주문 서비스는 바뀔 일이 없어서(구현체가 하나라) 그냥 나누지 않고 하나로 구현해도 되지 않나요?

안녕하십니까 테스트 코드 작성 중 궁금한 것이 생겨 질문드립니다. 1. memberService에서 member를 조회하셨는데, 예제여서 그런 것인지, 아니면 만약에 실제 DB를 사용하여 member를 조회한다면 memberService에서 실제로 조회를 하나요?? 저는 memberService가 회원가입을 하고 조회는 Repository에서 해야하는 것 아닐까? 라는 생각이 들었습니다,, 위의 코드가 잘못됐다가 아니라 정말 궁금해서 여쭤보고 싶습니다,, 2. isSameAs vs isEqualTo isSameAs는 same reference, isEqualTo는 equal based on value라고 구글링을 해서 알게되었는데, 여기서 findMember는 객체인데 어떻게 isEqualTo를 해도 되는지 궁금합니다,, 

안녕하세요 영한님 전 강의에서는 @Configuration이 있는 AppConfig클래스에서 CGLIB를 통해 AppConfig를 상속받은 AppConfig@CGLIB 클래스를 빈으로 등록한다고 하셨는데요, 이때는 AppConfig@CGLIB 클래스가 빈으로 등록되었기 때문에 빈 설정 파일에 등록된 모든 메서드가 CGLIB 기능을 거쳐서 빈 등록이 되었다고 생각했었습니다. 그런데 이번 강의와 같이 @Configuration과 컴포넌트 스캔을 통해서 빈 등록을 한다면 빈 등록이 되어있는 모든 객체가 CGLIB 기능을 거쳐서 빈 등록이 되는건지 여쭈어보고 싶습니다!

map 객체에 static을 안붙이면 nullpoint 예외가 나오는데 static을 붙이지 않으면 메모리를 공유하지 않기 때문인가요??

이전 강의에 싱클톤 빈(ClientBean)안에 PrototypeBean이 있는 예제에서 프로바이더 대신 프록시로 해봤는데, 프로토타입빈의 addCount()메소드를 타지 않아 count가 계속 0으로 나오더라구요   프록시로 해결할 수 있는 경우가 있고 ObjectProvider로 해결해야하는 경우가 따로 있나요?

1. 업로드해주신 pdf 파일 기준 18페이지, 19페이지에 주문과 관련된 클래스 및 인터페이스가 Order, OrderService, OrderSerivceImpl 이렇게 총 3개가 나오는데요 OrderSerivce은 말 그대로 역할을 위한 interface이고 OrderServiceImpl은 OrderService를 상속받은 클래스인데, 왜 Order라는 클래스를 하나 더 만드셨는지 궁금합니다. (Order안에 OrderServiceImpl의 내용을 다 넣어도 되지 않았을까? 굳이 왜 저렇게 소스를 작성하셨는지가 궁금합니다. 궁금한 점을 명확하게 표현하기가 어려운데, 주문이라는 행위 하나에 왜 Order과 OrderServiceImpl 두개의 클래스를 만들었는지?가 궁금합니다. OrderServiceImpl은 주문하는 과정이고 , Order은 영수증이라고 보면 되는걸까요?) - 2. 그리고 강의를 모두 수강 했는데, 강의 마지막에 JPA 실무 완전 정복 로드맵 (야생형) 수강하는 것을 추천하셨는데 최근에 남기신 댓글에서는 김영한의 스프링 완전 정복 MVC1편까지 보고 JPA 실무 완전 정복 로드맵 (야생형) 을 추천하시더라구요 스프링 완전 정복 로드맵( MVC2편 까지) 다 수강하고 JPA 실무 완전 정복 로드맵 (야생형) 으로 넘어가면 될까요 ?? 아니면 MVC1편만 수강하고 JPA 실무 완전 정복 로드맵 (야생형) 로 공부한다음에 돌아와서 MVC2편을 수강하면 되는건가요 ? 강의 매번 잘 듣고 있습니다. 좋은 강의 감사합니다.