안녕하세요! 김영한 선생님의 스프링 핵심 원리 강의를 수강하고 있는 학생입니다:)다름 아니라 setter 주입의 예제 코드와 관련하여 궁금한 점이 생겨서 질문을 남기게 되었습니다.강의 13:26에 나와있는 코드와 동일하게 setter와 생성자에 화면 출력 기능을 추가하였습니다. 그 결과, AutoAppConfig.class를 설정 정보로 하는 test 클래스를 실행하면 설명해주신 내용과 같이 생성자를 통한 의존 관계 주입이 먼저 일어나고 setter를 통한 의존 관계 주입이 나중에 일어남을 확인할 수 있었습니다.더 나아가 AutoAppConfig.class가 아닌 AppConfig.class를 설정 정보로 하는 test 클래스를 실행하면 콘솔 화면에 어떤 내용이 출력될지 호기심이 생겨 test.java.hello.core.beanfind 패키지에 위치한 ApplicationContextBasicFindTest 클래스를 실행하였습니다. 실행 전에 저는 orderService라는 이름의 스프링 빈이 등록되는 과정에서 orderServiceImpl() 생성자가 호출되기 때문에 System.out.println("1. OrderServiceImpl.OrderServiceImp"); 코드가 실행될 것이라 예상하였습니다.또한,(1) AppConfig.class엔 setMemberRepository()와 setDiscountPolicy()를 호출하는 코드가 없고 (2) AppConfig.class는 @ComponentScan를 사용하지 않기 때문에 setMemberRepository()와 setDiscountPolicy()가 @Autowired를 사용하고 있더라도 의존 관계를 자동으로 주입할 수 없어 해당 메소드(setter) 내부에 기재되어있는 System.out.println("memberRepository = " + memberRepository); 코드와 System.out.println("discountPolicy = " + discountPolicy); 코드는 실행되지 않을 거라 예상했습니다.하지만 저의 예상과는 다르게 setMemberRepository()와 setDiscountPolicy()가 모두 실행되었고 제가 어느 부분에서 잘못 생각하고 있는지 도움을 구하고자 질문을 남기게 되었습니다. 

[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예)[질문 내용]강의 너무 잘 들었습니다.객체 간 의존관계를 항상 의심하고 그것을 해결하는 것이 좋은 코드의 기본인 것 같습니다. 본 수업을 듣고 객체 간 의존관계를 해소하는 방법에 대해 명쾌하게 이해할 수 있었습니다.문득 궁금한 점이 생겼는데, 객체 간 의존관계 이외의 우리가 조심해야 하는 의존관계는 어떤 것들이 더 있을까요?하나의 단일 Spring App을 벗어나, System, 혹은 MSA 관점으로까지 확장했을 때, 우리가 조심해야 하는 X와 X 혹은 X와 Y 간의 의존관계는 어떤 것이 있을지, 조심스럽게 질문드려봅니다.감사합니다.

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

안녕하세요. 질문 하나 드리겠습니다. 의존하다 와 참조하다가 완전히 동일한 의미로 사용되는걸까요?'A가 B를 의존한다'라고 하면 'A가 B를 참조한다'로 동일하게 대체 되는 말인가요?

8:59초에 의존관계가 실행중에 동적으로 변하는 경우는 config파일만 바꾸면 된다고 말씀하셨는데 이 말이 무슨 말씀이신지 잘 모르겠습니다 config, 동적으로 A라는 객체가 B대신 C라는 참고하는 객체가 바뀐 다면, config뿐만 아니라 구현 class 또한 바뀐다고 생각해볼 수 있습니다 (동적으로 참조하는 동안 그 안의 매개변수가 달라지므로..) 그러면, 여기서 생기는 의문은 생성자가 필요하지 않을 떄는 어떤 조건에 따라 상황에 따라서는 의존 관계가 되거나, 다른 클래스로 의존관계가 바뀌거나, 의존관계가 없어지게 바뀌게 되는 것이 필요할 때 setter로 사용해서 이 구조를 좀 더 활용한다 라고 들렸는데 이렇게 말씀하신게 맞는가요? 그 다음 config를 바꾸면 된다는 말씀에 대한 의문은 그러면 그걸 처리할 때 서버에 접근하면, 초기 상태로 들어오는 함수를 설정한다던가 같은 이러한 방법 중 하나를 말씀하시는 건가요? 예를 들면,조건으로 의존관계가 바뀌게 되었는데 버튼을 클릭해서, 바뀐 의존관계가 원래대로 되돌아갔다..같은 거요 잘 모르겠어서 이 부분은 패스할텐데 어떤 뉘앙스의 말씀이신지 궁금하네요..  

[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예)[질문 내용]클래스 의존관계에서 가상의 시나리오로써 아직 데이터 저장소가 선정되지 않아서, 우선 인터페이스로 구현 클래스를 변경할 수 있도록 설계를 했다고 하셨는데 역할을 분리하고 의존관계를 약하게 하기 위해서 인터페이스 생성이 있어야하는건지 아니면 지금 강의에서 정해놓은 가상의 시나리오가 없다면 MemberRepository 인터페이스의 생성은 하지 않아도 되는건지 궁금합니다.

(관련 코드) static class DiscountService { private final Map<String, DiscountPolicy> policyMap; private final List<DiscountPolicy> policies; @Autowired public DiscountService(Map<String, DiscountPolicy> policyMap, List<DiscountPolicy> policies) { this.policyMap = policyMap; this.policies = policies; System.out.println("policyMap = " + policyMap); System.out.println("policies = " + policies); } (강의에서 설명) DiscountService는 Map으로 모든 DiscountPolicy(부모 인터페이스)를 주입 받는다. 이때 fixDiscountPolicy(자식 클래스), rateDiscountPolicy(자식 클래스)가 주입된다. (질문) DiscountPolicy는 인터페이스고 이것을 상속 받는 객체가 rateDiscountPolicy랑 fixDiscountPolicy입니다. 위 설명 대로라면 부모를 주입 받았을 때 자식까지 다 주입 받는 건가요? 자식을 주입 받았을 때 부모까지 주입 받는 거 아니었나요? 제가 상속에 대해 잘못 알고 있었던 건가요?