[토비의 스프링] 제어의 역전 - 오브젝트 팩토리 활용, 제어권의 이전을 통한 제어관계 역전

제어의 역전

오브젝트 팩토리 활용

어떤 ConnectionMaker 구현 클래스를 사용할지 결정하는 기능이 중복돼서 나타나고 있다.

public class DaoFactory {
    public UserDao userDao(){
        return new UserDao(new likelionConnectionMaker()); // ConnectionMaker 구현 클래스를 서언하고 생성하는 코드의 중복
    }

    public AccountDao account(){
        return new AccountDao(new likelionConnecionMaker()); // ConnectionMaker 구현 클래스를 서언하고 생성하는 코드의 중복
    }
}    

중복 문제 해결을 위해 분리하는 것이 가장 좋은 방법이다.

```java
public class DaoFactory {
    public UserDao userDao() {
        return new UserDao(new LikelionConnectionMaker());
    }

    /*분리해서 중복을 제거한 ConnectionMaker타입 오브젝트 생성 코드*/
    public ConnectionMaker connectionMaker(){
        return new LikelionConnectionMaker();
    }
}

제어권의 이전을 통한 제어관계 역전

제어의 역전이라는 건, 프로그램 제어 흐름 구조가 뒤바뀌는 것.
제어의 역전에서는 오브젝트가 자신을 사용할 오브젝트를 스스로 선택하지 않는다. 당연히 샌성하지도 않는다. 또 자신도 어떻게 만들어지고 사용되는지를 알 수 없다.
모든 제어 권한을 자신이 아닌 다른 대상에게 위임하기 때문이다.

우리가 사용한 예제

UserDao와 DaoFactory에도 제어의 역전이 적용되어 있다.
ConnectionMaker의 구현 클래스를 결정하고 오브젝틀르 만드는 제어권 UserDao에게 있었으나 DaoFactory로 넘어갔다.
자신이 어떤 ConnectionMaker 구현 클래스를 만들고 사용할지를 결정한 권한을 DaoFactory에 넘겼으니 UserDao는 능동적이 아니라 수동적인 존재가 되었다.
UserDao 본인도 팩토리에 의해 수동적으로 만들어지고 자신이 사용할 오브젝트도 DaoFactory가 만들고 초기화해서 자신에게 사용하도록 공급해주는 ConnectionMaker를 사용할 수밖에 없다.
UserDao와 ConnectionMaker의 구현체를 생성하는 책임도 DaoFactory가 맡고 있다. 이것이 제어의 역전(IoC)이 일어난 상황이다.