<aside> 💡
단순하게 표현하자면 data source, account repository, transfer service 등을 bean으로 각각 정의하고, data source를 repository에, repository를 service에 각각 constructor에 넘겨줌으로써 configuration을 정의한다고 볼 수 있다. 따라서 Config class에는 위 각각의 bean instance들이 선언되어 있으며, 이 Config instance class의 reference를 SpringApplication.run() constructor에 넘겨줌으로써 app 설정이 끝난다고 볼 수 있다.
Person() 에서 ()는 constructor call로 이해하면 된다.
</aside>
How Spring DI Container Works
Bean이라는 이야기가 많이 나오는데, bean은 Spring IoC container에 의해 manage 되는 object들을 통칭한다. Spring의 지배를 받는 객체들.
쉽게 말해 Spring에서 사용되는 annotation들이 Spring에게 IoC container로 집어넣어! 라고 지시한다고 생각하면 쉽다.
IoC Container라고 불리는 것은 실제 Inversion of Control이 일어나는 module들을 담고 있는 container이기 때문이다.
일반적으로는 Spring 같은 framework가 없다면 개발자가 객체와 그 dependency들의 생성과 관리, 호출 등에 responsible for 하지만, IoC의 경우에는 creating and manaing object를 Spring이 대신 해준다는 점에 있다.
그럼 스프링은 쓰지 않는다고 해도 개발자가 어차피 코드를 작성하고 이 코드를 실행하는 과정에서 어떤 프로그램이 들어간다고 하면 그것 역시 IoC라고 할 수 있지 않나? 라는 물음을 가졌음.
compiler execution의 경우에는 compiler가 object가 어떻게 create되는지 등에 대한, 또는 injection 등에 대한 관리를 개발자 대신에 해주는 것이 아니라 단순히 compile into bytecode의 역할을 한다는 차이가 있음.
new keyword를 대신 붙여준다던가 이런게 아니기 때문에.
Spring IoC의 경우에는 개발자가 instruction을 작성하고 (class def나 annotation등) Spring에게 뭘 만들면 되는지에 대해 알려줘서 실제 creation of objects (beans), their dependencies, lifecycle 등을 Spring이 직접 생성한다고 보면 됨.
POJO = Plain Old Java Object 아무 constraint가 걸려있지 않은 일반 java code를 뜻함
잠깐 다른 생각: event driven
JS는 single-threaded 이고 Java는 multi-threaded인데, 예를 들어 A를 fetch해오고 B를 계산하여 두 값을 이용해 C를 만들어내는 로직이 있다고 해보자. JS의 경우에는 A를 fetch 해오는 동안 B를 계산하고 fetch가 끝나면 (event) 다시 하던 일을 진행한다 정도로 이해를 하고 있는데, 그럼 java의 경우 A와 B를 서로 다른 thread에서 실행한다고 했을 때 A가 fetch되어 왔을 때 일종의 event handler가 필요하지 않은가에 대한 질문이었음.