안녕하세요!구글 검색을 해봐도 명확한 답을 찾기가 어려워 질문을 남깁니다.assertThat(bean).isInstanceOf(RateDiscountPolicy.class); 처럼 검증을 할 때isInstanceOf가 어떻게 동작을 하는건지 잘 모르겠습니다.assertThat(bean).isInstanceOf(DiscountPolicy.class); 해도 테스트 통과를 하더라구요 답변 부탁드립니다. 감사합니다.

강의내용을 되짚어 보다가 문득 궁금증이 생겨 질문드립니다. 스프링 컨테이너를 직접 만들지 않아도 빈 객체들을 주입 받을 수 있는데, 스프링 내부에 컨테이너가 있는 걸까요? 내부에 컨테이너가 있는게 맞다면 어떤 종류의 컨테이너이며, 어떤 라이프 사이클을 가지고 동작하는 건가요? 공식 문서에도 컨테이너를 만들고 사용하는 것에대해서만 설명하고 내부에 컨테이너가 있다는 말은 찾지 못했는데, 이런 내용은 어떻게 확인 할 수 있을까요? 알려주신 것 같이 컨테이너(Config)를 직접 만들어 쓰는 경우가 많나요? 주로 어떤 상황에서 많이 쓰이나요?   감사합니다!

1. 스프링빈은 객체를 생성한다.2. 의존관계 주입을 한다.3. 이후 필요한 데이터를 사용 할 수 있는 준비가 된다.   강의 듣다가 명확하게 이해하고 싶어서 질문드립니다.   의존관계 주입후 필요한 데이터를 사용 할 수 있는 준비가 된다고 하는데 그렇다면 생성자로 모든 데이터와 DB 커넥션을 해주는 작업을 한다면   의존관계주입이 발생될때 해당 초기화 했던 작업들은 다 무시가 되나요?

ApplicationContext말고 구체화된 클래스(예: AnnotationConfigApplicationContext)를 쓰는 이유가 getBeanDefinition을 쓸 수 없어서라고 하셨는데, 그 이유가 무엇인가요? AnnotationConfigApplicationContext가 구현한 여러가지 인터페이스중, ApplicationContext가 아닌 다른 인터페이스가 getBeanDefinition이라는 메서드를 제공하기 때문이라는 말씀이신가요?

안녕하세요! 네이버 지도 이미지 가져올 때 지도 이미지를 byte 배열로 읽어와서 직접 만든 파일에 쓰는 작업을 하는 부분에서   int read = 0; byte[] bytes = new byte[1024];   (1) while ((read = is.read(bytes)) != -1) { outputStream.write(bytes, 0, read);  }   (2) while ((read = is.read(bytes)) != -1) { outputStream.write(read);  }   실행해보면 기능은 둘 다 정상적으로 작동하는 것 같은데 (1)과 (2)의 차이점을 자세히 설명해주실 수 있나요?   감사합니다.

IoC, DI, 그리고 커네이너 강의 질문입니다. DI 설명 중 주입은 런타임 시라고 되어있는데 컴파일 시점 아닌가요?? 컴파일 시점에 이미 다 주입이 되고, 런타임에는 주입된 것을 사용한다고 생각하는데 이해가 좀 안되어서요 ㅜ.ㅜ 컴파일 시점에는 주입은 일어나지 않고, 스프링을 빌드(런타임)할 때, 주입이 일어난다는 의미 일까요??

학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://docs.google.com/document/d/1j0jcJ9EoXMGzwAA2H0b9TOvRtpwlxI5Dtn3sRtuXQas/edit#heading=h.w2tomwsznga7)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://docs.google.com/document/d/1xCQKit-1V6l6ObeCe49St33RHPzLF_P_c3o7aSDTKs0/edit#heading=h.7dhnp46ven0v)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용] 💡 DI (Dependency Injection) - 의존관계 주입 의존하는 객체를 직접 생성하는 것이 아니라, 외부에서 생성한 후 주입하는 것. 3가지 조건이 필요 클래스 모델이나 코드에는 런타임(실행) 시점의 의존관계가 드러나지 않는다. (= 정적인 클래스 의존관계가 아니다)(= 동적인 객체 인스턴스 의존관계이다) => 인터페이스에만 의존하고 있어야 한다 런타임 시점의 의존관계는 외부에서 결정한다 외부에서 실제 구현 객체(사용할 오브젝트에 대한 레퍼런스)를 생성하고 클라이언트(사용할 오브젝트)에 전달(주입)함으로써 의존관계가 연결되는 것이다 예를 들어 private Car myCar = new 벤츠(); => Car가 인터페이스고 벤츠가 구현 객체라면, 런타임 이전에, 즉 코드상으로 벤츠 클래스를 의존하는 것을 알 수 있다 private Car myCar; => 이러면 Car에 대해 무슨 차가 들어올지 알 수 없다.(런타임 시점의 의존관계가 드러나지 않으므로) => 즉 이렇게 인터페이스에만 의존하고 의존관계 주입이 발생할 수 있다. 💡 IoC (Inversion of Control) - 제어의 역전 프로그램의 제어 흐름(ex:메소드나 객체의 호출작업)을 개발자가 결정하는 것이 아니라, 외부에서 결정(관리)하는 것. 즉 객체를 개발자가 Member member = new Member(); 이런식으로 만드는 것이 아니라, 스프링이 스스로 객체를 생성해서, 필요한 곳에 사용할 수 있게 해줌! ​ 1 AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class); cs ​ 위 코드 단 하나만 실행했을 뿐인데, 우리는 ac.getBean을 통해, 원하는 객체를 사용할 수 있음!!!!! 참고로 DI도 제어의 역전에 포함되는 기술이며, IoC는 좀더 광범위하게 쓰인다! 🧾 부분 정리 스프링은 IoC, DI와 같은 기술을 사용함으로써 자바만으로는 DIP(의존관계 역전 원칙)와 OCP(계방-폐쇠 원칙)을 지켜가며 객체지향적으로 설계하는데 어려움이 있었는데, 이를 해결. 즉 스프링을 사용하면 좋은 객체 지향 애플리케이션을 개발하기 편해지며, 스프링은 이를 도와주는 프레임워크. 스프링이 좋은 객체 지향 애플리케이션을 개발하는데 도움을 주는 프레임워크인 것 처럼, 스프링 부트는 스프링의 기술들을 좀 더 편리하게 사용하는데 도움을 주는 프레임워크.   제가 정리한 내용들인데, 혹시 맞게 이해한건지요.. 너무 어려워서 여러차례 강의 반복하여 들으며 정리했습니다

인터페이스에는 안붙이고 구현체에만 @Component를 붙이는 이유는뭔가요?

TestConfig에서 rateDiscountPolicy이 DiscountPolicy타입인데 다른데서 의존할때도 DiscountPolicy에 의존하고 있으니까 DiscountPolicy타입으로 하는게 좋다라고 하셨는데 그게 무슨말인지 잘 모르겠어요.. 예를들어서 설명해주실 수 있나요....?

안녕하세요? 영한님 강의를 너무나도 잘 듣고, 실무에 적극 활요하며 성장 중인 주니어 개발자입니다. 먼저, 항상 좋은 강의 제공해주셔서 감사합니다. (벌써 3번째 듣는중인 강의입니다!)   다름이 아니라, 최근에 영한님께서 추천해주신 객체지향의 사실과 오해라는 책과, 오브젝트라는 책을 정독했어요. SOLID원칙에 조금 더 자세하고 정확하게 대해서 알게 되었고, 객체를 설계하는 법, 책임주도 설계 등 다양한 객체지향 원칙들을 배우고 학습하였는데   이를 실무에 어떻게 적용해나가야 할지 궁금합니다.   Q1. 강의 중 [조회한 빈이 모두 필요할 때, List, Map] 에 나온 내용과 같이, 하위의 구체 타입 클래스들을 모두 Spring Bean으로 등록시키고  애플리케이션 컨텍스트가 실행되는 시점에 의존관계를 맺어주고, 필요한 상황에 따라서 필요한 Bean을 찾아서 알고리즘을 수행하면 되는 걸까요? 강의에서 말씀해주셨던 Strategy 패턴과 같이 다른 디자인 패턴들도 비슷한 방식으로 적용해나가면 될지?에 대한 궁금증이었습니다.   Q2. 그렇게 된다면, 특정한 인터페이스를 설계하고 그 인터페이스를 구현하는 객체들은 모두 Spring Bean으로 등록되어야 할 것 같은데  방식이 맞을까요?   Q3. 그리고 외부에서 어딘가 협력하는 객체의 구체 타입에 대한 정보를 알고 있고 전달해주어야 하는데, 예를 들어 강의에 나온 것처럼 파라미터에 구체 타입에 대한 문자를 받고 진행한다면 컨트롤러 레이어에서 해당 문자를 전달 해주면 컨트롤러 계층은 호출하는 서비스 계층이 어떤 클래스들과 협력하는지에 대한 정보를 알아야 하므로, 이는 캡슐화가 위반되는 것이 아닌가 싶기도 합니다. 왜 이렇게 생각했는지 말씀드리자면 1) 컨트롤러 계층에서는 Serivce 클래스가 누구와 의존하고 있는지 알아야 합니다. 2) Service 클래스가 의존하는 대상이 추상화여도 그 추상화의 구체 인스턴스의 종류들에 대해서 알고 있어야 합니다. (그래야 원하는 알고리즘을 수행 가능) 3) 캡슐화는 단순히 객체의 내부 상태를 숨기는 것 이상의 의미를 가진다고 생각합니다. 만약 구체 인스턴스의 종류가 삭제된다면 분명 컨트롤러 레이어에서도 변경에 대한 여파가 있을 것 같다는 생각이었습니다. 4) 이를 무시하고도 실무에서는 보통 이런식으로 구현을 많이 하는 편일까요?   Q4. 제가 너무 Controller - Service - Repository의 일반적인 MVC 레이어에서 벗어나지 못하는 것이라고 생각이 들기도 했습니다. 일반적으로 대규모 서비스를 운영하는 회사에서도 한 마이크로 서비스 내에서 Controller-Service-Repository 구조를 가져가는지 궁금합니다. 네이밍을 조금 다르게 한다던지, 패키지 구조가 조금 다르다던지.. 그런 내용들이 있을까요? (현재 프로젝트 구조는 멀티 모듈화 시켜서 협력 패턴이 최대한 다른 컨텍스트에서도 재사용 될 수 있도록 프레임워크/라이브러리화 시키면서 설계해보려고 노력 중입니다. 그래도 애플리케이션 모듈은 C-S-R 구조를 벗어나기가 힘든 것 같아요)     작은 스타트업에서 주니어 혼자 끙끙 앓고 있어 답답한 마음에 여기에라도 질문을 올려봅니다. 너무 막연한 질문이라, 답변 주시기 어려울 것 같은 부분이 있다면 답변 안 주셔도 괜찮아요. 강의 제공 받는 것만으로도 저에게는 정말 큰 도움이 돼요 (사실 저도 어떻게 질문할지 막막해서 제가 봐도 어렵네요..) 항상 도움 주셔서 감사합니다 영한님 :)  

임의로 만든 json 파일 다루는 과정에서 한글이 깨집니다.   InputStream is = Project01_C.class.getResourceAsStream(src); InputStreamReader isr = new InputStreamReader(is, "UTF-8"); BufferedReader br = new BufferedReader(isr);   우선 구글링 해보고 정확한 원리는 모르겠지만 이렇게 해서 br을 토큰화시키니 한글이 안 깨지더라고요.   혹시 궁극적으로 이클립스 인코딩 설정을 기본설정이 아닌 utf-8로 설정하는게 좋을까요? (이러면 기존 프로젝트 한글이 다 깨지네요ㅠㅠ)

1. InitializingBean와 DisposableBean "개발자가 코드를 고칠 수 없는 외부 라이브러리에는 적용할 수 없다."라고 설명하셨습니다. 외부 라이브러리의 코드를 제가 직접 고칠 수 없는 건 알겠는데, 그렇기 때문에 해당 메소드를 적용할 수 없는 이유를 좀 더 상세하게 알려주시면 감사하겠습니다. 2. initMethod와 destroyMethod "코드가 아니라 설정 정보를 사용하기 때문에 코드를 고칠 수 없는 외부 라이브러리에도 해당 메소드를 사용할 수 있다."라고 설명하셨습니다. 여기서 해당 기능이 설정 정보를 사용한다는 말의 뜻과 그렇기 때문에 외부 라이브러리에서 사용할 수 있는 이유를 좀 더 상세하게 알려주시면 감사하겠습니다.

안녕하세요. 간단한 질문인데요. 자동 빈 등록과 수동 빈 등록의 범위가 궁금합니다. 컴포넌트 스캔을 통해 컴포넌트 어노테이션이 붙은 객체들을 자동으로 등록하는 것을 자동 빈 등록이라고 한다면, 그 외 모든 빈 등록은 수동 빈 등록이라고 볼 수 있을까요? 그렇다면, 기술 지원 객체의 경우는 수동 빈 등록을 추천해주셨는데, 따로 강의 초반에 만드신 @Configuration과 @Bean으로만 구성된 AppConfig와 같은 Class를 만들어 구현하는 것으로 이해하는게 맞을까요?    

1. 생성자를 제외한 대부분의 빈은 "컨테이너 생성 -> 빈 객체 생성 -> 의존관계 주입 -> 초기화"의 라이프사이클을 가진다고 하셨습니다. 그러면 생성자 빈의 라이프 사이클은 어떻게 되나요? 강의 15분 48초에서 "생성자 주입 같은 경우에는 객체를 생성해야 되기 때문에 스프링 빈 생성 단계에서 어느정도 일어납니다. "라고 하셨는데, 좀 더 구체적으로 알고 싶습니다.   2. 초기화 콜백, 소멸 전 콜백에 관한 질문입니다. 초기화 콜백은 "의존관계 주입 완료 후 호출"이라고 하셨고, 소멸 전 콜백은 "빈이 소멸되기 직전에 호출"이라고 하셨는데, 여기에서 호출이라는 게 뭔가요? 무엇을 호출한다는 건지요?

생성자 주입 방법은 필수, 변경 가능성이 없는 경우에 사용된다고 하셨고,  setter 주입 방법은 선택, 변경 가능성이 있는 경우에 사용된다고 하셨습니다. 여기에서 '필수/선택'과 '변경 가능성'이 무슨 뜻인지 잘 모르겠습니다. 좀 더 상세한 설명 부탁드립니다.

파라미터 값으로 (빈 이름, 타입)이나 (타입)을 받는다고 설명하셨는데, 예제에서는 getBean(beanDefinitionName)으로 빈 이름만 들어온 거 같습니다. 파라미터 값으로 (빈 이름)만 올 수 있는 건가요?

안녕하세요 강사님! 학원에서는 스프링 원리에 대해서는 안알려주고 무작정 이렇게 코드 짜는거다라고 알려줘서 너무 답답했었는데 강사님 강의를 듣고 속이 뻥~! 뚫렸습니다! 이론강의를 정말 안좋아하는데 강사님 수업은 너무 재밌고 다음 내용이 궁금해서 밤새가면서 봤네요 :D (입문 강의 때는 완전히 이해가 안가더라도 일단 입문을 학습하는게 좋다는 강사님 말만 믿고 따라했더니 정말 되더라구요) 핵심원리 수업을 듣고나서 스프링이 이런거구나 이래서 이 코드를 작성했던거구나 하고 이해는 가는데 다른 사람에게 설명하라고 하면 그정도 실력은 안되는 것 같아 고민입니다. 이걸 어떻게 활용을 해야할지도 문제구요. 사실 제가 학원에서 배웠던 스프링이랑 비슷하면서도 굉장히 다르다는 생각을 합니다. 현재 상황에서 HTTP와 MVC를 듣고 JPA 로드맵으로 넘어갈 지, 핵심원리를 한번 더 복습하고 핵심원리에 대해 완전히 익히고 넘어가야할 지 정말 고민이 됩니다. 이후 강의를 듣다보면 이번 강의에서 놓친 부분들까지 체계를 잡게 될지가 의문스러운 것 같습니다. 어떻게 해야할까요?

안녕하십니까 강사님!! 수업 너무 재밌게 잘 듣고있습니다! 수업을 듣다 궁금한점이 생겨 질문 남깁니다. 요번 강의에서 예시코드로  DiscountPolicyConfig 클래스를 만들고 수동으로 Bean에 주입이 되었는데요, 이때 자동 등록하는 Configuration가 discountPolicyConfig의  Configuration까지 bean으로 주입해버릴 것 같은데,  이 부분은 어떻게 해결할 수 있을까요? 이전에 배운 excludeFilters를 사용하면  Configuration이 있는 모든 클래스의 의존성 주입을 막게돼서 discountPolicyConfig에서 수동으로 주입하는 메서드들이 작동하지 않을것 같네요... 배웠던 것 같기도한데, 헷갈리는 부분이 있어 질문 드립니다!! 항상 좋은 강의 감사합니다 :)

글 작성이 제대로 안되서, 코드에 대한 설명이 미흡할 수 있는 점 미리 양해구합니다.ㅠㅠ 저는 집 색깔을 랜덤으로 정할 때, 기본값이 미리 정해져 있는 상태에서 사용자가 특정 부분만 색깔을 랜덤으로 돌릴 수 있도록 함수를 작성했습니다. 아래와 같은 두가지 함수를 실험삼아 해봤는데요. 첫번째 함수는 랜덤값을 불러오는 헤더를 외부에서 매개변수로 가져오고 두번째는 함수 안에다가 선언했습니다. 그런데, 두번째 함수는 랜덤값이 다 같게 적용이 되더군요. 분명 랜덤값은 _rnd.getInt(0,6);에서 가져올텐데 왜 두개의 함수의 결과가 다른지 이해가 가지 않습니다.ㅠㅠ 제가 분명 기본이 부족한 거일 수도 있겠지만, 인터넷 검색으로도 썩 답변이 안되어 질문글 올립니다. 감사합니다.

https://kwonnam.pe.kr/wiki/java/lombok/pitfall파라미터 선언 순서 변경에 따른 생성자에서 파라미터 순서로 변화로 인해 발생할 수 있는 치명적인 오류를 사전에 방지하기 위해 @AllArgsConstructor, @RequiredArgsConstructor 의 사용은 자제하는 것을 권하던데Spring 프로젝트에서도 마찬가지로 적용되는 경우가 있을까요?예를 들어, 컨테이너 안에 같은타입의 빈이 여러개인 충돌 문제가 아니라하나의 클라이언트에서 같은 타입의 의존성을 두개 주입을 요구할 경우가 있을까요? private final DiscountPolicy discountPolicyFirst; private final DiscountPolicy discountPolicySecond; 이렇게 될 경우, 순서가 중요할거 같지만@Qulifier 같은 방식을 사용하지 않으면  같은 의존성만 주입될거 같고@Qulifier를 사용하면 의존성을 요구하는 필드의 순서 문제가 자동으로 해결될거 같기도 하구요아니면 현실적으로 이런 방식을 쓰기보단Map이나 List를 사용하여 자체적으로 로직을 만들어  상속하는 같은 계열의 빈을모두 가져와서  선택적으로 여러개의 의존성을 사용하는게 맞을까요?추가적으로 궁금한 점이 있습니다.@Qualifier를 사용하여  같은 타입의 빈이 두개 이상 있을때 선택할 수 있다고 하셨는데@RequiredArgsConstructor를 사용한 경우엔 자동으로 생성자를 만들어줘서 @Qualifier를 사용하여 의존성을 주입할 수 없는건가요?