애플리케이션 로딩 시점(조립 = 스프링 컨테이너 올라가고 나머지가 세팅되는 시점)할때 한번 변경이 될 뿐, 한번 세팅이 된 이후에는 memberService를 변경할 일이 없는데, setMemberService가 Pulic하게 노출된다.
따라서 의존관계가 실행 중에 동적으로 변하는 경우는 거의 없기 때문에 생성자 주입을 권장한다.
* 실무에서는 주로 정형화된 컨트롤러, 서비스, 리포지토리의 경우 컴포넌트 스캔을 사용한다. * 정형화되지 않거나, 상황에 따라 구현 클래스를 변경해야 하는 경우 설정을 통해 스프링 빈으로 등록한다. EX ) 직접 설정 파일을 운영할 때 장점 : MemoryMemberRepository의 경우, 아직 저장소를 정하지 않았기 때문에 인터페이스로 구현 클래스를 언제라도 변경할 수 있도록 설계해 두었다. 이때 MemoryMemberRepository를 다른 Repository로 변경할 때, 기존의 운영중인 코드를 하나도 변경하지 않고 바꿔치기 하기위해 이런 방식을 사용 Memory -> Db 로만 바꾸면 완료
@Autowired를 통한 DI는 스프링이 관리하는 객체(@Service, @Repository로 등록)에서만 동작한다. 스프링 빈으로 등록하지 않고, 내가 직접 생성한 객체에서는 동작하지 않음 - 스프링 컨테이너에 올라가는 것들만 Autowired 기능이 동작
