IOC 이란 무엇일까요?
단어 그대로 '제어의 역전'입니다.
아래 그림을 살펴보겠습니다.
제어의 주체의 변화에 중점을 두고 보면 이해가 쉽습니다.
내가 제어 주체인 App1 은 외부 라이브러리를 불러와 내 입맛에 맞게 사용하는 전통적인 형태의 절차적 프로그래밍이라고 볼 수 있겠습니다.
라이브러리가 늘어나면 늘어날수록 프로그램이 커지면 커질수록 '내가' 제어해야하는 책임은 계속 늘어나게 됩니다.
누군가(외부)가 프로그램 App2 을 만들었습니다.
App2 에서는 누군가가 만든 코드가 내가 만든 코드를 호출하여 사용합니다.
이제 App2 에서는 '나'는 많아지는 책임에서 벗어나 행복할 수 있습니다.
'나'는 멋진 프로그램을 만든 누군가에게 고맙다고 생각하며 리스펙합니다.
App2 에서 누군가 만든 코드는 프레임 워크(Spring, Laravel, Django, Rails) 이라는 이름으로 불리고 있습니다.
소스 코드의 흐름이 내 코드에 있었다면 외부로 흐름이 변경되는 경우 Inversion Of Control 이 생겼다고 볼 수 있습니다.
IOC 를 구현한 대표적인 예시로는 DI 패턴, Strategy 패턴 등이 있습니다.
IOC Container? DI Framework?
프레임 워크에서 IOC 를 구현하는 방법으로 컨테이너라는 개념이 도입되었습니다.
이 컨테이너는 보통 객체 의존 관계를 관리하며 의존성 주입하는 역할을 담당합니다.
보통 IOC를 구현하여 IOC Container 라는 포괄적인 이름으로 불리기도 하며 DI를 구현하고 있어 DI Framework 라는 이름으로 불리기도 합니다.
명칭 정의가 확실하게 되지 않은 부분이 있어 두 가지가 혼용되어 사용된다고 합니다.
명칭보다 역할에 집중하여 자동으로 객체 의존 관리를 해주는 Container 라고 생각하면 될 거 같습니다.
- 제어의 권한을 외부 소스 코드가 관리하는 형태가 되는 경우 제어 주체가 소스 작성자에서 외부 소스로 이동하면서 IOC(Inversion Of Control) 가 발생되었다라고 볼 수 있습니다.
- DI 를 구현하는 프레임 워크에서는 객체 의존성을 관리하는 컨테이너가 존재하는데 보통 IOC Container 또는 DI Framework 라고 불립니다.
- IoC 란 코드의 흐름을 제어하는 주체가 바뀌는 것입니다.
- 전통적인 절차적 프로그래밍에선 자신의 코드가 직접 사용할 오브젝트를 결정하고, 결정한 오브젝트를 생성하고, 생성한 오브젝트의 메서드를 호출하는 식이지만 IoC를 적용하면 모든 제어 권한을 자신이 아닌 다른 대상에게 위임합니다.
