프록시는 싱글톤으로 되어있지만  진짜 빈을 찾을때는 싱글톤 객체가 되면 안될거 같은데  프록시가 진짜 빈을 요청 할때마다 스프링 컨테이너는 요청이 들어올때마다 새로운 request scope 객체를 생성해서 넘겨주나요 ?

안녕하세요, 선생님. 이번 강의에서 주석에 대해 배웠는데요. 신기하게 /** */ 주석 안에 @기호를 붙이면 주석에 색이 들어오게 되더라고요. 이게 주석이 풀린건지 아니면 수업 중에 말씀하신 프로그램 설명 문서를 자동으로 만들어 주는 툴과 관련이 있는건지 궁금해서 질문 남깁니다. 답변해주시면 감사하겠습니다^^

안녕하세요, 실무에서 초급 개발자로 있는 학생입니다. 다름이 아니라, 강의에서 Impl 접미사는 보통 구현체가 1개일때 관용적으로 사용한다고 말씀해주셨는데 , 구현체가 1개인 경우에도 interface를 선언하고 이를 구현해주는 이유가 있나요? 실무에서 코드를 보아도 모두 interface를 선언하고 이를 구현해주고 있는데 이에 대해 무의식적으로 따라하기만 했지 이유를 생각해본 적이 없어서요.  수정개발을 하면 구현체 뿐 아니라 interface도 같이 변경해야해서 번거롭다고 느낄때도 있었구요. 정리하자면, 구현체가 1개인 경우 굳이 interface를 선언하고 구현하는 이유와 그에 따르는 장점 (단지 확장성 뿐인지)등이 궁금하여 이렇게 질문드립니다. 감사합니다.

안녕하세요 강사님!  스프링 부트를 사용한 것과 사용하지 않고 하는 방법이 헷갈려서 아래 질문들이랑 강의를 토대로 정리해봤는데 제가 이해한 내용이 맞나요? 번거로운 질문 드려서 죄송합니다ㅜ /** * # spring boot 사용 x * new AnnotationConfigApplicationContext(AutoAppConfig.class); * 1. ApplicatonContext(스프링 컨테이너) 생성 * 2. AutoAppConfig를 스프링 빈으로 등록 * 3. AutoAppConfig에 @ComponentScan이 달려있으므로, @Component 어노테이션이 달려있는 클래스를 스프링 컨테이너에 빈으로 등록 * * # spring boot 사용 * 1-1. @SpringBootApplication 이 붙어있는 class(이 예제에서는 CoreApplication)의 main 함수가 실행. * 1-2. @SpringBootTest 테스트 실행 -> @SpringBootApplication 어노테이션을 찾아감 * 2. 위 둘 중 하나를 하면 스프링부트 내부에서 자동으로 ApplicationContext (스프링 컨테이너)를 생성. * 3. @SpringBootApplication에는 @ComponentScan이 포함되어 있음. * => @Component 어노테이션이 달려있는 클래스를 스프링 컨테이너에 빈으로 등록 * (@Configuration에도 @Component가 포함되어있으므로 이 어노테이션이 달려있는 설정 클래스도 빈으로 컨테이너에 등록, * 이때 만약 @Bean 어노테이션이 있으면 빈을 컨테이너에 등록) */ 감사합니다!

안녕하세요. 항상 강의 즐겁게 잘 보고있습니다. AppConfig를 제외한 클라이언트 코드에 변경이 없다고 하셨는데, 이 어플리케이션을 만약 배포한다면 하나의 서버로 동작하게 되는게 아닌가요? ㅠ 이 부분이 헷갈려요. discount, member, order 패키지들이 클라이언트라 말씀하시는건지 궁금해요. 아니면, 3개의 지점으로 이루어져서, (클라이언트 / 사용자가 데이터를 사용하게 되는 지점) <-> (서버 / hello.core 의 핵심 내용) <-> (설정자 / AppConfig) 이런 아키텍쳐가 되어서, 설정자만 업데이트해도 클라이언트와 서버(서버란 표현이 애매하네요, 이것도 서버이자 클라이언트라고 볼 수도 있으려나..?)는 업데이트하지 않아도 되어서 클라이언트라고 표현하신건가요 !?

안녕하세요. 비전공자 백엔드 개발자 준비중입니다. 강사님 좋은 강의 덕분에 spring 공부에 큰 도움이 되고 있습니다. AppConfig에서 역할과 구현을 나누어 구현체를 쉽게 바꿀 수 있다는 원리는 이해하였습니다. 여기서 제가 궁금한게 어떻게 AppConfig에서 메소드를 만들어 구현체를 넣어주면 생성자를 통해 받을 수 있는지, 그 원리가 궁금합니다. 생성자에서 this.객체 = 객체 이런식으로 받는데, AppConfig에서 넣어준 값이 어떻게 해서 이런 원리로 주입이 되는건가요? 제가 생성자 개념이 부족해서 이해가 안되는 것 같기도 하네요... 그리고 Test에서는 AppConfig  인스턴스를 생성해서 넣어줬는데, 왜 실제로는 그렇게 해주지 않은건가요? 메모리 낭비 때문에 그런걸까요? 인스턴스 생성 해서 넣어주는 부분은 이해가 되는데, 생성자로 주입해주는 부분은 원리가 이해가 되질 않네요.

@Component에서도 적용이 될까 싶어서 @Component(initMethod = "init", detroyMethod = "close") 를 해봤는데 컴파일 에러가 나네요. 이 방법은 수동 등록에서만 가능한 방법인건가요?

안녕하세요~ 강의를 듣다가 궁금한 점이 생겨서 질문 남깁니다! @Bean의 initMethod, destroyMethod 속성을 사용하면 외부 라이브러리에도 초기화, 종료 메서드를 적용할 수 있다고  하셨는데 외부 라이브러리 코드를 고칠 수 없는 상황에서 어떤 의미로 적용이 가능한지 궁금해서 질문 드립니다!외부 라이브러리에 이미 구현되어있는 메소드를 초기화나 종료 시 구현해야하는 메소드로 지정해준다는 뜻인가요?? 답변 주시면 감사드립니다! 또, 항상 강의 너무 잘 보고있습니다! 좋은 강의 찍어주셔서 정말 감사드려요 :))

안녕하십니까 강의 항상 감사드립니다. 다름이 아니오라 생성자 주입을 사용하는 경우에 생성자의 Parameter 명을 rateDiscountPolicy로 네이밍하였고 동시에 테스트를 위해 FixDiscountPolicy 클래스 정의 위에 @Primary를 작성하여 과연 '@Primary방법'과 '@Autowired 필드명 방법'이 동시에 사용되었을 떄 어떤것이 적용 되는지 확인을 해보았습니다. 그 결과로 아무리 생성자의 Parameter명을  'Spring Container의 Bean Naming'에 따라 네이밍 했다고 하더라도 @Primary 애노테이션이 기재된 타입이 우선순위로 책정되어 OrderServiceImpl은 RateDiscountPolicy가 아닌 FixDiscountPolicy에 의존하게 되더군요 제가  아직 단위 테스트 코드 작성에 단련되지 않은터라 제가 한 테스트 결과가 맞는 것인지 여쭙고자 질문 남기게 되었습니다. 답변 부탁드립니다. 항상 현업에 바쁘신 와중에도 늦은시각 까지 강의질문 답변에 신경써주셔서 감사합니다. ^^

안녕하세요 강사님, 몇가지 질문 드리겠습니다. ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ- 질문 1. 제가 지금까지의 흐름을 맞게 이해하였는지 궁금합니다. 이전까지의 강의에서는(@ComponentScan 등장 전) AppConfig에서 @Configuration을 달았고, @Configuration에 의해 그 밑에 있던 @Bean들을 조회하여 빈을 생성하고 등록하는 방식으로 진행이 됐습니다. 테스트 코드에서 ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);위 코드를 통해서 AppConfig의 빈이 등록될 수 있었고  거기에서 @Configuration을 인식하여 그 안에 있는 @Bean들을 모두 인식해 필요한 빈들을 등록하였습니다. 결론적으로, 지금까지는 어떠한 컴포넌트 스캔도 이뤄지지 않았으며 모든 빈 등록은 new Annotation~~Context(AppConfig.class)에 의해 생성된 AppConfig 빈에 의해 이루어졌습니다. 제가 맞게 이해한건가요? ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ 질문 2. @ComponentScan을 사용한다면 ApplicationContext 가 굳이 필요없지 않나 하는 생각이 듭니다. AppConfig와 @Configuration을 통해 수동으로 빈을 등록한다 하더라도.. 컴포넌트 스캔의 범위에 AppConfig를 두면 알아서 모든 빈들이 문제없이 생성될 것입니다.(굳이 new Annotation~~Context(AppConfig.class) 를 통해 AppConfig 빈을 등록하지 알아도 알아서 스캔되어 등록될 테니까) @Component, @Autowired를 통해 의존성 주입을 해결해도 컴포넌트 스캔의 범위만 잘 설정해준다면 모든 빈들은 문제없이 생성되고 주입될 것입니다. 그렇다면 실제 프로그래밍에서는 ApplicationContext는 쓰이지 않는다고 봐도 되나요? 아니면 강의에서 해오셨던 것처럼 테스트 코드에서 getBean을 사용하기 위해서만 사용된다고 보면 될까요? 그것도 아니면 실제 프로그래밍에서도 사용되는 어떠한 용도가 있을까요? ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ질문 3. 다른 질문에서 지금까지 CoreApplication을 전혀 사용하지 않았기 때문에 CoreApplication 없이 프로젝트를 돌려도 똑같이 돌아갈 것이라고 말씀하셨는데요. CoreApplication에 대한 직접적인 사용은 없었지만 CoreApplication에 @SpringBootApplication이 있고 그 안에 @ComponentScan이 있고CoreApplication은 hello.core 하위에 존재하니까 hello.core 하위의 패키지를 모두 컴포넌트 스캔 할 것이고..  그럼 CoreApplication은 컴포넌트 스캔으로 프로젝트에 영향을 미치고 있던 게 아닌가요? 어떻게 이 중요한 녀석을 빼놓고도 똑같이 동작할 수 있는 것인가요? 이에 대한 해답으로 new Annotation~~Context(AppConfig.class)를 통해 모든 빈 등록을 했으니 CoreApplication의 @ComponentScan이 없어도 되는 것인가? 라는 생각이 드는데요.  만약 이게 맞다면 하나 더 궁금해지는 것이..  이대로라면 빈 등록이 CoreApplication의 @ComponentScan에 의해 한 번, AppConfig의 @Configuration에 의해 또 한 번. 총 두 번의 빈 등록이 일어나는데 이것에 의한 에러가 발생하지 않는 이유가 무엇인가요?  이번 실습에서 이와 같은 오류를 막기 위해 @Configuration을 컴포넌스 스캔 범위에서 제외하는 코드를 따로 작성해줬던 것이 아니었나요? ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ 질문 4. 이전 강의에서 스프링 컨테이너가 @Configuration을 통해 싱글톤을 가능하게 하는 방법을 설명해주셨는데요.(@Configuration이 동록된 클래스를 상속받아 AppConFIg@@@CGLIB으로 사용하는 방법) 만약 AppConfig와 @Configuration이 없이 @ComponentScan을 통해서만 빈 등록과 의존성 주입을 모두 처리할 경우에는 어떤 식으로  싱글톤을 유지할 수 있게 되나요?  혹시 이게 너무 지엽적인 부분이라면 "그냥 스프링 컨테이너가 알아서 잘 해준다." 정도로 받아들이고 넘어가도 괜찮을까요? ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ  지식의 소용돌이가 아직 완벽히 정리되질 않아 질문이 너무 길고 횡설수설 합네요. 죄송합니다. 강의 재밌게 잘 듣고 있습니다.  감사합니다!

강의 내용을 복습하다가 막힌곳이 있는데 AppConfig 클래스에 Configuration 애노테이션이 있으니깐 결론적으로 스프링 컨테이너가 되고  그 이하의 Bean들을 관리해주는 건가요?? Configuration 애노테이션이 붙어있으면 붙어있는 클래스가 모두 스프링 컨테이너가 되는건가요??

안녕하세요.  수업을 듣다가 Singleton이 DIP를 위반한다는 점에서 여쭤보고 싶은 점이 생겼습니다. 클라이언트에서 의존성을 주입받는 다고 하고, A, B 두 클래스가 있을 때 B가 A를 상속받는 Singleton이라 가정하겠습니다. 클라이언트가 생성자 주입을 받든, Setter 주입을 받든 A에 의존하게 하고, 클라이언트에 의존성을 주입하는 Config(?)가 A를 넣는자리에 B를 넣어주면 DIP 문제가 해결되는 것이 아닌가요? 어째서 Singleton을 쓰면 DIP가 위반되는지 궁금합니다

안녕하세요 현재 1학기만 남은 졸업예정학생입니다 2개월뒤에 졸업작품으로 스프링부트로 웹사이트 개발예정이있습니다. 3학년때 스프링 ( jsp, oracle, mybatis) 으로 근본적인 이해없이 그냥 복붙으로 뚝딱뚝딱 사이트를 만들었던 경험이있는데 이번 졸업작품은 프론트단/백단 모두 혼자서 완벽히 이해하며 만들어 보는것을 목표로 하고있습니다. 제가 궁금한점은 1.  영한님의 스프링입문,기본 편 강의를 수강했고 현재 활용1편(야생형)까지 들은상태입니다. 스프링 기본편은  알려주시는것들이 너무 많은데 제가 제대로 소화하지 못하는것같아서 한번 듣기는 했지만 나중에 다시 꼭 들어야겠다고 생각하고있습니다. 제가 많이 부족한것인지는 몰라도 아직까지 선뜻 스프링부트로 사이트를 만들어 봐야지 하는 정도의 개념은 잡히지 않은것같습니다. 향후계획은  JPA기본편을 수강-> 활용1편 복습-> 그후 야생형 순서 로 가려고하는데 어느정도 강의를 듣고나서 시작해보시는걸 추천하시나요?? 2. 오픈예정인 실전MVC, db접근 등의 강의는 야생형 로드맵 까지 완료한후에 듣는것을 추천하시는건가요??? 당장 웹사이트를 만들어야하는 상황이면 JPA를 깊게 파는것보다 실전 MVC, DB 강의를 듣는것이 조금더 효율적일까요? 제가 생각하는것은 야생형 로드맵을 다 듣고나면 강의가 추가로 오픈될것같아서 그후에 듣고싶지만  빨리 여러강의를 수강하면 제가많이 부족한탓에 흡수를 못할것같아 걱정이됩니다 강의가 정말좋아서 처음으로 강사님의 모든 로드맵의 과정들을 전부듣는다는것을 전제하에 질문드리게되었습니다 ㅠㅠ

정리하는 내용에서 클라이언트 코드라는 단어가 나오는데, 정확히 클라이언트란 무엇일까요..?  client라는 단어가 사실 여기저기서 자주나오다 보니 헷갈립니다. 저는 프론트엔드 개발자라서 그런가 client 코드라고 하면, 브라우저에서 작동하는 프론트 코드가 떠올라서요.. 어떻게 이해를 하면 좋을까요?  소프트웨어 공학 관점에서 말하는 Actor, 특정 Actor(여기서는 주문을 하는 손님)에 대한 코드라고 보면 되는걸까요?

AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class); 으로하셨는대 ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class); 이렇게 하지 않으신 이유가 궁금합니다 이전까지는 이방법으로 했기때문에 궁금해졌습니다

실무를 하다보면, 개발기간내 시간에 쫒겨 비지니스 로직 구현만 하고, 테스트 코드 작성은 미뤄두다 결국 못하는 경우가 많습니다. 강사님 강의를 듣다보면 로직 구현 이상으로 테스트 코드 작성에 시간을 할애해야 할 정도로 중요하게 얘기를 하시는걸 느낄수 있는데요. 꼭 테스트 코드를 작성해야 하는 이유를 뭐라고 생각해야 할까요? 사실, 그동안은 테스트 코드는 형식상 작성하는거다라고 우선순위를 낮춰 생각해왔거든요. 제가 잘못생각하고 있었다면 조언 부탁드립니다.

수업 내용에 대한 질문은 아닙니다.^^ 다이어그램이 간단해보여 업무 정리로 좋을꺼 같에요. 어느 툴 사용하셨는지 여쭤봅니다.

안녕하세요 강사님, 질문 있습니다. 다형성만으로는 OCP, DIP를 위배할 수밖에 없다고 설명하시며 그에 대한 대책으로 스프링이 나온 것이라고 말씀해주셨는데요. 아마 이는 이전 강의에서 진행하셨던 @Configuration, @Bean을 통한 스프링 컨테이너에 객체를 등록하는 방식을 말씀하는 것일 거라고 생각합니다. 다만 의문점이 드는 부분은.. "스프링을 개발한 개발자들 또한 OCP, DIP 위배 문제에 대한 고민을 하였고 그 해답으로 스프링 프레임워크를 만들었다." 라고 함은.. 스프링이 등장하기 전에도 SOLID라는 개념은 존재했다는 것이겠지요? 그런데 OCP, DIP 위반 문제를 해결하기 위해 스프링을 만들었다? 그렇다면 스프링이 등장하기 전에는 어떤 방식으로도 SOLID를 모두 충족시킬 수 없었다는 말인가요? 그렇다면 저 SOLID라는 개념을 처음 제시했을 사람은.. 문제에 대한 해결책도 없이 그냥 객체지향 설계의 이상향만 제시했을 뿐인 건가요?  알쏭달쏭 하네요; 이번 강의도 잘 듣겠습니다. 감사합니다! ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ 바로 다음 강의에서 스프링 등장 이전 배경에 대한 설명이 다시 간략하게 나오네요. 스프링이 없이 OCP, DIP를 지켜가며 개발을 하다보니 배보다 배꼽이 커지는 일이 발생했고 그래서 스프링을 만들었다구요. 이로써 첫 질문에 대한 답은 해결이 되었는데.. 음.. 저 스프링 없이 SOLID를 유지하는 코딩 방식에 대한 건 너무 지엽적인 부분이겠죠??ㅠㅠ

ApplicationContext ac = new AnnotationConfigApplicationContext(TestBean.class);해당 코드를 통해서 TestBean 클래스가 컨테이너에 빈으로 등록이 되었으나,TestBean 클래스 내부의 @Autowired 어노테이션의 warning을 살펴보니 **Autowired members must be defined in valid Spring bean** 라는 경고 문구를 볼 수 있었습니다.해당 내용은, 자동의존주입을 받기 위해서는 현재 클래스 또한 스프링 빈으로 등록되어 있어야 한다는 의미로 해석했습니다. 결론은, 이러한 경고가 뜨는 이유를 잘 모르겠습니다.ide가 이 시점에 경고를 잡아주지 못하는 것인가요? 한가지 더 질문을 드리자면,TestBean 클래스에 @Configuration 애노테이션을 붙이게 되면, @Autowiredpublic void setNoBean2(@Nullable Member noBean2) { System.out.println("noBean2 = " + noBean2);}해당 코드에서 noBean2 부분에 빨간 밑줄이 생깁니다. (Could not autowire. No beans of 'Member' type found.)Member 타입의 빈을 찾을 수 없기 때문에 자동주입을 할 수 없다는 의미인데, 당연히 Member는 빈이 아니지만 왜 @Configuration 애노테이션을 붙였을 때 빨간 밑줄이 뜨는지 이유가 궁금합니다. @Autowiredpublic void setNoBean1(Member noBean1) { System.out.println("noBean1 = " + noBean1);}해당 코드 역시 @Configuration 애노테이션이 붙었을 때 noBean1에 빨간 밑줄이 뜹니다.

AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class); 위 부분에서 AnnotationConfigApplicationContext 구현체 타입을 사용한 이유가 있을까요? 보니까 AnnotationConfigApplicationContext 타입에서만 getBeanDefinition 메서드를 사용할 수 있더라구요 그러면 AnnotationConfigApplicationContext이 ApplicationContext이 구현체인데 왜 getBeanDefinition을 못하는지가 궁금합니다. (하지만, ApplicationContext에서는 여러 구현체 중에 AnnotationConfigApplicationContext 있는것은 확인했으나 AnnotationConfigApplicationContext클래스에서는 ApplicationContext가 아닌 AnnotationConfigRegistry 구현체로 서로 다르게 명시 되어 있는 것도 궁금합니다. - 구현체는 하나의 인터페이스(하나의 부모)로만 구현한다고 알고 있습니다.)