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

의존성 주입 학습 중에 @Autowired에 private를 쓰는 방식보다 @RequiredArgsConstructor과 private final를 쓰는 방식이 더 우수하다는걸 학습하고 리팩토링 하는 중에 문제가 생겨서 질문을 올리게 되었습니다.   몇몇 수정이 되지 않는 코드들이 있어서 사진과 함께 질문 올리고 싶습니다.   1. OAUTH 토큰 발급 관련 코드 기존 필드 주입 생성자 주입으로 변경시 컴파일 에러   2. 기존의 코드를 상속해서 constructor을 재선언한 코드 기존 필드 주입 방식 생성자 주입으로 변경시 마찬가지로 컴파일 에러   뭔가 근본적으로 잘못한것 같은데 어디서부터 손을 대야될지 모른채 고치고 틀리고만 몇시간째 반복하고 있습니다   잘 부탁드리겠습니다.

안녕하세요 선생님 강의를 듣던 도중 의문이 생겨 질문 드립니다. 의존 관계 주입에 대해 강의를 듣던 도중 AppConfig를 활용하여 각 추상객체에 구현객체를 만들어 주입함으로서, OCP 와 DIP 위반을 해결하셧는데요, 여기서 이렇게 각 MemberService와 OrderService에 대한 구현체 생성을 하는 과정에서 new MemoryMemberRepository라는 코드가 중복이 되는것이 마음에 걸려, 아래처럼 한번의 생성을 통해 두 구현체에 한번에 주입하는 코드로 변경 해 보았는데요. 먼저, 이렇게 코드를 수정하여도, MemberApp 또는 OrderApp 코드는 잘 실행 되는데요, 여기서 저의 질문은, 제가 생각한것처럼  하는 방법도 추후에 다른 문제를 야기 시킬 가능성이 있는지 궁금합니다..