여기서 말하는 도메인과, 나중에 package로 만드는 domain은 같은 의미인가요 ??? 도메인이 정확히 무엇인지 안와닿아서 알려주시면 감사하겠습니다 !

안녕하세요. 영한님~직장다닐때 패키지로 스프링부트 jpa 실무 로드맵 전부 구매하고이제 취업준비하면서 시작해보려는데 커리큘럼이 많이 바뀐거 같던데db1,2편과 고급편까지 꼭 다 들어야 하나요?? 신입으로 취업을 준비중인데 금액적인 부분에서 부담이되서 jpa로드맵에서 해결이가능하면 결제 안하고 싶은데 답변 부탁드립니다.

학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용]공부 중에 제가 이해한 것이 맞는지 아닌지 의문이 들어 질문 남깁니다.//1번 AppConfig appConfig = new AppConfig(); memberService = appConfig.memberService(); //2번 AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class); MemberService memberService = ac.getBean("memberService", MemberService.class);1번에서 AppConfig 객체를 직접 만들어서 memeberService를 가져오는 것은 순수 Java 코드로 짜기 때문이고 2번에서 AnnotationConfigApplicationContext에서 getBean()메소드를 통해서 가져오는 것은 스프링으로 전환하여 스프링을 이용하는 것이라고 보면 되나요?+ ) 클래스 자료형을 다음과 같이 ApplicationContext로 사용하는 것보다 AnnotationConfigApplicationContext를 클래스 자료형과 생성자를 쓰는 것은 기능상 이유 때문인가요?ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용]  void configurationTest(){ ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class); //구체 타입으로 꺼내면 원래 좋지 않지만 테스트를 위해 Impl를 꺼냄 MemebrServiceImpl memberService = ac.getBean("memberService", MemebrServiceImpl.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); Assertions.assertThat(memberService.getMemberRepository()).isSameAs(memberRepository); Assertions.assertThat(orderService.getMemberRepository()).isSameAs(memberRepository); }위의 configurationTest 중 memberRepository가 같은 인스턴스를 공유하고 있지 않아 원인을 AppConfig에서 찾을 수 있었습니다.아래 코드와 같이 AppConfig에서 실수로 static을 넣었기 때문인데 static을 사용하여 정적 메소드를 생성할 경우 왜 싱글톤이 성립하지 않는지 관계가 이어지지 않아서 질문드립니다. // 원 코드 @Bean public MemberRepository memberRepository() { System.out.println("call AppConfig.memberRepository"); return new MemoryMemberRepositroy(); } // static @Bean public static MemberRepository memberRepository() { System.out.println("call AppConfig.memberRepository"); return new MemoryMemberRepositroy(); }

코틀린에서 자바코드를 사용할 때 플랫폼 타입 사용에 유의하여야한다고 하셨습니다.팁으로 자바 코드를 널 가능성을 확인하는 코드를 삽입하던지 아니면 코틀린으로 한번 래핑하라고 하셨는데 여기서 코틀린으로 한번 래핑하라는게 무슨 의미인지 잘 모르겠습니다4강입니다 

안녕하세요:) 강의 잘 듣고있습니다. 수강 중 궁금한 점이 생겨 질문드립니다! NetworkClient 클래스와 BeanLifeCycleTest 클래스에서 의존관계 주입과 초기화에 관한 질문입니다. 제가 생각하는 게 맞나 의문이 들어 제 생각을 적어봤습니다.  <BeanLifeCycleTest 클래스, lifeCycleTest() 테스트> ConfigurableApplicationContext ac = new AnnotationConfigApplicationContext(LifeCycleConfig.class) 1. 테스트 코드에서 ac라는 스프링 컨테이너를 생성한다. 스프링컨테이너를 생성할 때 구성정보로 LifeCycleConfig.class를 지정해줬다.@Configurationstatic class LifeCycleConfig {@Beanpublic NetworkClient networkClient() {NetworkClient networkClient = new NetworkClient();networkClient.setUrl("http://hello-spring.dev");return networkClient;} }2. LifeCycleConfig.class에 있는 @Bean이 붙은 메서드들을 스프링 컨테이너에 빈으로 저장한다. networkClient라는 이름을 가진 빈이 생성된다.2-1. networkClient라는 빈에서 NetworkClient 타입의 객체networkClient 가 생성된다.2-2. 객체가 생성됨과 동시에 NetworkClient() 생성자를 호출해 맨 처음 "생성자 호출, url = null이" 출력된다.2-3 NetworkClient 타입인 networkClient에 setUrl("http://hello-spring.dev") 을 통해 url에 값을 저장한다.3. https://www.inflearn.com/questions/653260 위 글을 살펴보면 답변에서의존관계 주입이 setUrl() 다음에 이뤄진다고 하셨는데,,,  setUrl() 호출 다음이면 위의 제 생각 중 2-3번 다음인가요,,,?  의존관계 주입 방법에 생성자를 통한 주입이 있으므로 생성자 호출 시 의존관계 주입이 이뤄지는 건가요,,,?  아님 스프링 컨테이너에 빈이 생성되면서 의존관계 주입이 일어난다. 크게 생각하면 되는건가요,,? 어디서 일어나는 건지 질문드립니다. 4. "스프링 빈은 객체를 생성하고, 의존관계 주입이 다 끝난 다음에야 필요한 데이터를 사용할 수 있는 준비가 완료된다. 따라서 초기화 작업은 의존관계 주입이 모두 완료되고 난 다음에 호출해야 한다." 의존관계 주입이 완료되면 초기화 작업이 이루어진다고 수업 자료에 나와있는데요,초기화란 객체를 선언하고 값을 최초로 할당하는 것이라고 알고있습니다.그럼 위의 코드에서는 객체 생성, 즉 생성자 호출 후   setUrl()로 값을 주입하는 게 초기화 작업이 맞을까요..? 만약 맞다면 결론적으로 NetworkClient networkClient = new NetworkClient(); -> 의존관계 주입networkClient.setUrl("http://hello-spring.dev"); -> 초기화 작업이게 맞는건가요,,?이렇게 되면 3번에 언급되었던 게시글 답변 중, 스프링 컨테이너 실행 -> 스프링 빈으로 등록 -> setUrl() 호출 -> 의존관계 주입  -> 초기화 이 순서에 의문이 생기게 되는데 어떤 순서가 정확한지 질문드립니다!! 

Vcpkg를 이용해서 opengl, glew, glfw3 설치(20.4 참고)위 글을 보면 20.4를 참고하여 설치하라는 것 같은대요. 20.4가 어디에 있는지 무엇을 참고 해야하는지 모르겠습니다. 유튜브를 통해 c / c++을 듣고 api를 듣는 도중 해당 강의를 알게 되어 해당 강의를 우선적으로 듣고 api를 들어보는게 좋을 것 같아서 구매를 했는대요. 20.4 / 20.5 / 20.6 참고하라는 말이 있는대 어디를 들어가야 참고할 수 있는지를 모르겠습니다. 알려주시면 감사하겠습니다. ㅜㅠ

안녕하세요.강의 후반부 스프링 없는 순수한 DI 컨테이너로 메서도 호출을 한다면, 계속해서 객체를 새로 생성하는 예시를 보여주는 부분이 있습니다.여기서 궁금한 것은 AppConfig에 @Configuration 과 해당 클래스 메서드들에 @Bean 설정이 되어있는데, 이것들은 순수한 DI 컨테이너에서 의미없는 어노테이션들이 맞을까요?원래는 빼야하는데 그냥 안빼시고 설명하신 것 인지 궁금합니다.

[질문 내용]안녕하세요 항상 강의 잘 듣고있습니다! 제가 복습을 하던 중 궁금한게 생겼는데 제가 이해한 것이 맞는 지 확인하고 싶어요!질문 1. MemberServiceImpl의 경우 AppConfig를 사용했을 때 위와 같은 구조를 갖게 되는데 만약에 이때 스프링으로 전환하지 않고 사용한다고 가정한다면, 클라이언트의 요청이 100번 들어오면 마찬가지로 AppConfig객체도 100번 생성해야 하는 문제점이 발생하게 되는 것이 맞나요? 질문 2.만약에 스프링 컨테이너를 사용하게 된다면 스프링 컨테이너에 AppConfig를 등록하고 필요할 때 마다 쓰게 되니까 싱글톤으로 공유해서 사용하게 되는 것이 맞나요??

인스턴스라는 게 정확히 뭐죠..?기본적인 java지식이 있으나 너무 기본적이라 그런지..답변주시면 감사드리겠습니다 ㅠㅠ

Appconfig.class라고 해줄 때,.class의 의미는 무엇인가요?class를 호출하겠다는 의미일까요? :)

어디서 볼 수 있나요? 윈도우는 오른쪽 마우스 클릭해도 안 나와용

둘의 차이는 ApplicationContext가 상위 인터페이스라 기능이 적어서 AnnotationConfigApplicationContext()를 쓴다고 알고있는데 어차피이거나ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);이거나AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);결국 둘 다 new로 AnnotationConfigApplicationContext()를 구현해 줬으니 똑같은 기능을 사용할 수 있는 것 아닌가요?왜 ApplicationContext를 사용하면 getBeanDefinition()메소드를 이용할 수 없는 것이죠?

MemberServiceImpl과 MemberRepository 이렇게 2개가 의존관계에 있을 때 로그를 확인해보니1. MemberServiceImpl 빈 등록2. MemberRepository 빈 등록3. MemberServiceImpl에 MemberRepository 의존성 주입 (Autowired)이렇게 로그가 찍혔습니다.여기서 궁금한 점은 MemberServiceImpl 빈 등록이 가장 처음이라는 점이었습니다.구글링을 해보니 빈 등록시 Reflection API를 사용한다고 나와있었습니다. 그런데 MemberServiceImpl에는 기본생성자가 없습니다. 그래서 Reflection API를 사용하여 인스턴스를 어떻게 생성하는거지??? 의문이 생겼습니다.분명히 로그를 보면 MemberRepository가 주입되지 않은 빈객체가 생성된 것을 알 수 있습니다.그렇다면 Reflection API를 사용하여 기본생성자로 MemberServiceImpl 인스턴스를 생성했다는 것인데 MemberServiceImpl에는 기본생성자가 없습니다.실제로 테스트를 해봤습니다.생성자가 하나인 경우 @Autowired 붙이나 안붙이나 같은 효력을 가지므로 다음과 같이 테스트 하였습니다.@Component public class MemberServiceImpl implements MemberService{ private final MemberRepository memberRepository; public MemberServiceImpl(MemberRepository memberRepository) { this.memberRepository = memberRepository; } public MemberServiceImpl(MemberRepository memberRepository, String message) { this.memberRepository = memberRepository; }테스트를 해보니 기본생성자가 없어서 빈으로 등록을 못한다는 예외가 발생하였습니다.그런데 다음의 경우에는 기본생성자가 없어서 빈으로 등록을 못한다는 예외가 발생하지 않았습니다.@Component public class MemberServiceImpl implements MemberService{ private final MemberRepository memberRepository; @Autowired public MemberServiceImpl(MemberRepository memberRepository) { this.memberRepository = memberRepository; } public MemberServiceImpl(MemberRepository memberRepository, String message) { this.memberRepository = memberRepository; }단서는 @Autowired라는 것은 발견했습니다.그런데 구글링을 해도 @Autowired 가 기본생성자를 만들어주나? 이에대한 글을 찾기가 힘들었습니다.혹시 이와관련한 자료가 있다면 답변 주시면 감사하겠습니다~  

안녕하세요 좋은강의 감사합니다.제가 잘못한건지, array.plus(300)후 foreach 를 활용해 프린트를하여도 300이라는 값은 안나오더라구요..plus 확장함수를 살펴보니 새로운 객체를 copy 하여 return 해주던데,새로운 객체로 return 받아서 활용해야하지 않나요?예를 들어 val newArray = array.plus(300) 이런식으로요제가 잘못 생각한 것인지..ㅜㅜ별거아닌거 같긴한데 확인가능하실까요 ㅎ 

안녕하세요. NetworkConfig에서 객체를 생성한 후 setUrl()이 불리는데 의존관계 주입과 setUrl()을 부르는 타이밍? 순서를 알수 있을까요? 무조건 setUrl()을 부른뒤에 의존관계가 주입되나요?

강의는 현재 "관심사의 분리" 수강하고 있습니다.그전에, 여태까지 만들었던 주문과 할인 도메인이 OCP와 DIP를 어기고 있다는 것을 배웠습니다.그런데, OCP와 DIP를 어기지 않게 수정하는 것이코드 중 private final DiscountPolicy discountPolicy = new RateDiscountPolicy();를 사용하지 않고 AppConfig를 사용하는 것이더군요. 여기서 제가 궁금한 것은,객체지향 설계의 5가지 원칙이 S, O, L, I, D 라고 5가지나 나와 있는데저 코드 한 줄이 O, D를 동시에 어기는 것이 이상하다는 것입니다. (어쩌면 S, L, I 중에서 더 어기고 있는 것이 있을 수도 있고요)분명 서로 다르니까 5가지로 분리를 해놨을텐데, 문제 원인도, 해결 방법도 서로 동시에 공유하고 있습니다.구글에서 SOLID의 설명, 예시를 다 찾아봐도 문제 원인을 공유하는 경우가 많았습니다. OCP를 고쳤더니 DIP가 고쳐진다고 하면서로 해결 방법을 공유하고 있는 부분이 있다고 하면SOLID가 아니고 SOLI가 되어야 하지 않나... 생각합니다.확장에는 열려 있으나 변경에는 닫혀 있어야 하도록 유도하는 방법이, 의존 관계 역전을 막아 주기도 한다면 굳이 왜 서로 분류를 해놓은 건지 궁금해요. 이건 마치...강아지를 산책시키는 일 A와 유산소운동을 하는 일 B를 계획했는데A를 하니까 유산소운동이 되어서평생 B를 못하는 느낌입니다. 혹시 OCP는 지키는데 DIP는 어기는 코드가 있을까요? (혹은 그 반대)

섹션 3 - 새로운 할인정책 개발 강의에서 test 코드에서RateDiscountPolicy discountPolicy = new RateDiscountPolicy();관련하여 질문 있습니다. Q1.다른 test 코드에서는 자료형에 인터페이스 명을 적어서 선언했는데이번엔 구현체 명을 적어서 선언한 이유가 있나요 ? Q2.그렇지 않다면, 인터페이스 명으로 자료형을 선언할 때와 구현체 명을 선언할 때차이점과 어떠한 상황에서 선언이 되어야 하는지 궁금합니다 !

안녕하세요! effectively final 관련 궁금증이 있어 질문드립니다!Java에서 람다 사용시 effectively final 여야지만 되는 이유가 람다 외부 지역변수를 제어하는 스레드와 람다식을 수행하는 스레드가 서로 다를 수 있고, 지역 변수는 스택에 저장되는데 각 스레드가 다르면 서로의 스택을 공유하지 못하기 때문에 값을 복사하여 사용하는데 이 경우 값이 최신값임을 보장하지 못하기 때문이라고 알고 있습니다.Kotlin에서는 effectively final 하지 않아도 되는 이유가 잘 이해가 안가서 질문드립니다! 람다 시작 지점에 참조하고 있는 변수들을 모두 포획한다는 것이 Java에서와 마찬가지로 복사하여 값을 사용하는 것과는 다른 개념인걸까요?

주문과 할인 도메인 설계 강의 8:00 부터입니다.회원을 메모리가 아닌 실제 DB에서 조회하고, 정률 할인 정책을 지원해도 주문 서비스를 변경하지 않아도 된다고 하시는데 이전 강의 중 회원 도메인 설계에서 문제점으로 OCP, DIP 전부 다 위반한다고 하셨습니다. 이렇게 위반을 하니까 스프링을 사용해야 하는 것 같고요. 이 강의도 마찬가지로, OrderServiceImpl에서 private final MemberRepository memberRepository = new MemoryMemberRepository(); 를 사용함으로써 '회원을 메모리가 아닌 실제 DB에서 조회'하면 OrderServiceImpl 파일의 내용도 변경되어야 한다고 생각합니다. '회원을 메모리가 아닌 실제 DB에서 조회하고, 정률 할인 정책을 지원해도 주문 서비스를 변경하지 않아도 된다' 틀린 말 아닌가요?