IoC, DI, 그리고 컨테이너
이번시간에는 스프링의 핵심개념들인 IoC, DI, 컨테이너라는 용어를 학습해보자.
개발공부를 하다보면 꼭 스프링이 아니어도 제어의 역전이라는 개념을 많이 접했을 것이다.
이 개념은 클라이언트가 객체를 직접 호출하는게 아니라, 프레임워크 등 외부의 다른 대상이 객체를 직접 생성, 호출해주는 기법을 말한다.
객체를 사용하는 클라이언트가 객체를 직접 생성, 호출하는게 아니라서 제어의 역전이라는 이름이 붙었다.
말 그대로 제어권이 뒤바뀐다는 것임.
제어의 역전을 코드에 구현하기 전에는 클라이언트 객체들이 구현객체들을 스스로 생성하고 호출하곤 했다. 전체 어플리케이션의 제어 흐름을 클라이언트 객체들이 스스로 조종했다는 것임.
사실 이는 개발자 입장에선 자연스러운 흐름이다. 클라이언트 객체를 구현하는 당사자가 개발자이기 때문임. 즉, 개발자가 제어 흐름을 갖고 있다는 것이다.
반면 AppConfig등장 이후에 클라이언트 객체들은 그저 자신의 로직을 실행하는 역할만 하고, 프로그램 전체의 제어 흐름은 AppConfig가 가져갔다.
이게 무슨 말이냐면, 각각의 클라이언트 객체들은 필요한 인터페이스를 호출하지만, 이를 통해 어떤 구현객체가 딸려올지 모른다. 즉, 프로그램 전체의 제어 흐름을 모른다! 제어권이 없다.
애플리케이션 전체의 제어 흐름은 AppConfig가 갖고 있다. 심지어 서비스 클라이언트 객체들조차 AppConfig가 생성하고 실행한다.
위의 AppConfig를 보면 각 인터페이스가 필요할때 무엇을 반환해줄지도 AppConfig가 결정한다. 즉… OrderServiceImpl이라는 서비스 객체도 AppConfig한테 객체를 받아 쓰는 것 뿐만 아니라, 자기 자신도 AppConfig한테 선택되지 않을수도 있다는 의미임. 그리고 이 사실을 OrderServiceImpl은 절대 모른다. 사용영역과 구성영역이 철저히 분리되어 있기 때문임.