제어의 역전(IOC)

 

제어의 역전(IOC - Inversion Of Control)

앞서 우리는 UserDao를 분리와 확장이 잘 적용된 깔끔한 코드로 리팩토링하는 작업을 수행했다.
사실 우리가 역할을 넘어간 UserDaoTest가 있다.
테스트용으로 만든건데 DB커넥션 클래스의 결정과 UserDao와의 연결까지 맡고 있으니 문제가 있습니다. 이것도 분리해줘야 합니다.

지금부터 우리가 따로 분리해내어 만들 클래스는 팩토리 라는 이름으로 사용되는 클래스입니다.
팩토리 클래스의 역할은 객체의 생성방법을 결정하고 그렇게 만들어진 오브젝트를 돌려주는 역할을 합니다.
UserDaoTest에서 테스트 목적의 기능을 뺀 나머지를 한데 모아 DaoFactory라는 이름의 클래스로 만들겠습니다.

DaoFactory.java

그리고 UserDaoTest에서는 아래와 같이 사용을 하시면 됩니다.

UserDaoTest.java

그런데 만약 DAO가 많아지면 그럴때마다 UserDao 메서드와 같이 복사를 해서 다른 Dao 메서드를 만들어야 되고, 그렇게 되면 또다시 코드의 중복이 일어납니다.

ConnectionMaker 구현 클래스를 결정하는 부분을 따로 메서드로 뽑아내는것이 좋겠습니다.

DaoFactory.java

 
일반적으로 프로그램의 흐름은 main() 메서드와 같이 자신이 사용할 오브젝트를 직접 결정하고, 생성하고, 생성된 오브젝트의 메서드를 사용하는 과정의 반복입니다. 즉, 사용하는 쪽에서 제어하는 능동적인 성향을 가지고 있다고 말씀드릴 수 있습니다.
그러나 우리가 리팩토링 과정을 거치면서 UserDao는 자신이 사용할 오브젝트를 직접 선택하거나 생성하는 과정이 사라졌습니다.

즉, 제어권을 다른 대상에게 위임하고, UserDao는 그것을 받아서 쓰기만 하는 수동적인 상태로 변화했습니다. 이와 같은 구조를 제어의 역전이라고 합니다. 말 그대로, 원래 사용자가 제어하던 것이 역전 되었습니다. 위의 코드도 사실 제어의 역전이 적용된 코드입니다. 언제 적용이 되었을까요?
바로 DaoFactory를 추가하는 과정이었습니다. DaoFactory는 핵심로직인 Connection을 생성하는 역할을 맡은데다가, UserDao의 생성까지도 맡고 있기 떄문이죠 ~~
UserDao나 UserDaoTest는 DaoFactory가 제공하는 메서드를 사용할 수 밖에 없는 수동적인 상황이 된,제어의 역전이 적용된 상황입니다.

위와같이 대표적 IOC 프레임워크인 스프링을 사용하지 않고도 IOC를 적용시킨 셈이다.
단순한 기능에는 위와 같이 IOC를 적용시켜도 충분하지만, 애플리케이션 전반에 걸쳐 적용하려면 스프링과 같은 IOC 프레임워크의 도움을 받는것이 훨씬 유리합니다.

스프링은 IOC를 극한까지 적용하고 있는 프레임워크입니다. 앞으로 본격적으로 스프링이 제공하는 IOC에 대해 알아보자.