=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예)[질문 내용] 안녕하세요 강사님~!   롬복 어노테이션인 requiredArgsConstructor 가 있으면 컴파일 시점에서 생성자를 자동 생성해 주잖아요.   근데 해당 어노테이션 선언을 들어가 보면 Retention policy가 Source 로 돼 있어요.   제 생각으론 Compile 로 돼 있어야 컴파일 시점에 해당 어노테이션이 메모리에 남아있어 해당 어노테이션을 보고 생성자를 생성할 것 같은데 말이죠.   requiredArgsConstructor 의 Retention policy가 Source 로 돼 있어도 컴파일 시점에 생성자를 생성할 수 있나요?   감사합니다 ^0^

AppConfig만 사용해도 DI는 잘 됐던 거 같은데, MemberApp(스프링 컨테이너)까지 만들어서 사용하는 이유는 'DI 외에 다른 스프링 기능을 활용하기 위해서'가 맞는 거죠?

안녕하세요, 다른 분들의 질문을 참고해봐도 혼자서 이해하는게 너무 버거워서 질문을 남깁니다.   여기저기 출력문을 찍어보니   ConfigurableApplicationContext ac = new AnnotationConfigApplicationContext(LifeCycleConfig.class);   에서 "스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존 관계 주입 -> 초기화 콜백" 까지 한번에 된다는 사실을 알았습니다.   public class BeanLifeCycleTest { @Test public void lifeCycleTest() { System.out.println("rmfjadjswptodtjdeh;a??1"); ConfigurableApplicationContext ac = new AnnotationConfigApplicationContext(LifeCycleConfig.class); System.out.println("rmfjadjswptodtjdeh;a??2"); NetworkClient client = ac.getBean(NetworkClient.class); ac.close(); } @Configuration static class LifeCycleConfig { @Bean public NetworkClient networkClient() { NetworkClient networkClient = new NetworkClient(); //networkClient.setUrl("http://hello-spring.dev"); System.out.println("stestesatestasetasetaset"); return networkClient; } } } 1. setUrl은 생성자 주입처럼 동시에 의존관계가 주입되는게 맞을까요?? 2. 여기서 setUrl은  다른 분들의 질문을 보니 값 주입이라고 하던데 의존관계 주입이나 값 주입이나 비슷하다고 이해하고 넘어가면 될까요?? 3. afterPropertiesSet() 은 따로 호출을 하지 않았는데, 어떻게 호출을 하는건가요?? 4. 초기화 콜백은 '무조건' 호출이 되는 걸까요? 실제로 setUrl을 주석 처리해도 콜백함수가 호출이 됩니다.   질문이 조금 많지만 답변 부탁드립니다 ㅠㅠ 감사합니다.

안녕하세요 강의를 듣다가 궁금증이 생겨서 질문 드리게 되었습니다. Built-in Object타입의 toString의 경우 어떤식으로 사용 할 수 있나요?   제가 테스트 해본 코드는 var object = {1: 123}; console.writeline(object.toString()); 이었습니다만 그 결과가 [object object]로 나왔습니다.   예상으로는 property의 이름이나 값을 출력해줄 것이라 생각했는데 단지 []괄호와 object만 출력이 되어 내부가 어떻게 돌아가는지 잘 이해가 가지 않아 질문드리게 되었습니다.   감사합니다.  

학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.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. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용]   안녕하세요. 질문 있습니다.   store.put(member.getId(), member)에서 value로 member.getName()이 와야하지 않나요? 왜 member인지 모르겠습니다..ㅠ

안녕하세요! 진짜 영한님 강의는 최고네요. 감사합니다. 듣다가 질문이 생겼는데요. `@Configuration`을 주석처리하고 `@Bean`만 남겼을 때 빈으로 등록되긴 하는데 여러개가 등록(싱글톤 X)된다고 하셨잖아요.   여기서 헷갈리는 이유는, "Bean은 스프링컨테이너에서 관리되는 싱글톤 객체이다."라는 이론적 내용과, "같은 이름의 Bean이 여러개 생성되기도 한다"라는 이 강의의 실험 결과과 충돌해서인데요. 엄밀한 정리를 하고 싶어서 질문드려요. 일단은 "같은 이름의 Bean이 여러개 생성되기도 한다"가 먼저 가능성 측면에서 맞는 얘기고, "Bean은 스프링컨테이너에서 관리되는 싱글톤 객체이다."는 정상적(일반적)인 방식으로 Bean을 등록한다면이라는 전제가 깔렸을 때 맞는 얘기일 거로 생각 됩니다. 그럼, 아래 내용중에는 무엇이 맞는 걸까요? 영한님이 보여주신 실험처럼, `@Configuration`을 누락하면 동일한 Bean이 여러번 생성되는 경우가 있는데 이 때, 1. `memberRepository`라는 메서드가 3번이나 호출되었는데, 새로 생성될 때마다 기존에 먼저 생성되었던 빈을 덮어쓰기(override)한다. 고로 생성만 N번 될 뿐이지, 결과적으로는 스프링 내에서는 싱글톤으로 존재한다.(* 만일 이게 맞다면 컴파일타임/런타임 모두 에러가 안나고, 동작 자체에는 문제가 없겠네요. 리소스는 많이 잡아먹겠지만요.) 2. `memberRepository`라는 메서드가 3번이나 호출되어 총 3개의 인스턴스가 빈으로 각각 등록되었다. 고로 이름을 같지만 3개의 빈이 실제로 모두 존재한다. (* 만일 이게 맞다면, 이 경우 빈을 사용하기 위해 주입할 때 컴포넌트 스캔 결과, ConflictingBeanDefinitionException이 뜨게 되겠네요.)   --- 앗. 질문이 잘못된 부분이 있어서 수정했습니다.

[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예)[질문 내용]컴포넌트 단원의 @ComponentScan에 관한 질문입니다   package hello.core; import org.springframework.context.annotation.ComponentScan; import org.springframework.context.annotation.Configuration; import org.springframework.context.annotation.FilterType; @Configuration //ComponentSacn은 Spring빈을 전부 검색해서 담는 과정을 수행함, 정확히는 @Componet가 붙은 녀석들을 전부 담아줌 @ComponentScan( //AppConfig에 등록한 Configuration을 제외해주는 과정ㅇ excludeFilters = @ComponentScan.Filter(type = FilterType.ANNOTATION, classes = Configuration.class) ) 위의 코드는 예제 AutoAppConfig.java 파일안의 코드입니다. 이렇게 하면 AppCongif, TestConfig에서 주가되는 Bean을 예외로 하는것은 이해했습니다. 여기서 궁금증이 생기는데 자기 자신에도 @Configuration이 추가 되어있는데 자기 자신의 @Configuaration은 예외 처리를 안해주는것인가요? 질문을 정리하면 @ComponentScan을 통한 예외처리를 진행할 때 자기 자신의 클래스는 제외하고 예외처리를 진행하는것인지 궁금합니다.

안녕하세요!구글 검색을 해봐도 명확한 답을 찾기가 어려워 질문을 남깁니다.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를 만들어 구현하는 것으로 이해하는게 맞을까요?