1.4 제어의 역전(IoC)

 

토비의 스프링 3.1

1.4 제어의 역전(IoC)

1.4.1 오브젝트 팩토리

: 이 장에서 목표는

1) UserDao와 ConnectionMaker 구현 클래스의 오브젝트를 만드는 것

2) 이 두 개의 오브젝트가 연결돼서 사용될 수 있도록 관계를 맺어주는 것

 -팩토리

: 여기서 팩토리란 객체의 생성 방법을 결정하고 그렇게 만들어진 오브젝트를 돌려주는 클래스를 말한다.

1. UserDaoTest(Client)에 담겨 있던 UserDao와, ConnectionMaker관련 생성 작업을 DaoFactory로 옮김.

public class DaoFactory{
    
    public UserDao userDao(){
        ConnectionMaker connectionMaker = new DConnectionMaker();
        UserDao userDao = new UserDao(connectionMaker);
 
        return userDao;
    }
 
}

2. UserDaoTest에서는 DaoFactory에 요청해서 미리 만들어진 UserDao 오브젝트를 가져와 사용하게 만듦.

public class UserDaoTest{
 
    public static void main(String[] args) 
            throws ClassNotFoundException, SQLException{
 
        UserDao dao = new DaoFactory().userDao();
    }
}
 

-설계도로서의 팩토리

: 애플리케이션의 컴포넌트역할을 하는 오브젝트(실질적인 로직 담당) 와 애플리케이션의 구조를 결정하는 오브젝트(설계도)를 분리했다는 데 가장 의미가 있다.

1.4.2 오브젝트 팩토리의 활용

: 만약 DaoFactory에 UserDao외에 다른 DAO 생성 기능을 넣으면 어떻게 될까?

new DConnectionMaker라는 ConnectionMaker 구현 클래스의 인스턴스를 만드는 부분이 반복돼서 나타나게 되고, 클래스를 바꿀 때마다 모든 메소드를 일일이 수정해야 된다.

문제점,  DAO 생성 메소드의 추가로 인해 발생하는 중복

public class DaoFactory{
 
    public UserDao UserDao(){
        return new UserDao(new DConnectionMaker());        
    }
 
    public AccountDao accountDao(){
        return new AccountDao(new DConnectionMaker());
    }
 
    public MessageDao messageDao(){
        return new MessageDao(new DConnectionMaker());
    }
 
}

 

해결방법, ConnectionMaker의 구현 클래스를 결정하고 오브젝트를 만드는 코드를 별도의 메소드로 뽑아내자.

public class DaoFactory{
    
    public UserDao userDao(){
        return new UserDao(connectionMaker());
    }
 
    public AccounDao accountDao(){
        return new AccountDao(connectionMaker());
    }
 
    public MessageDao messageDao(){
        return new MessageDao(connectionMaker());        
    }
 
    public ConnectionMaker connectionMaker(){
    //분리해서 중복을 제거한 ConnectionMaker타입 오브젝트 생성코드
        return new DConnectionMaker();
    }
  
}

DaoFactory는 오브젝트 수준의 가장 단순한 IoC 컨테이너 내지는 IoC 프레임워크라고 불릴 수 있다. 

UserDao는 팩토리에 의해 수동적으로 만들어지고, 자신이 사용할 오브젝트도 팩토리가 공급해주는 것을 수동적으로 사용해야함.

 

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

 제어의 역전이라는 건, 간단히 프로그램의 제어 흐름 구조가 뒤바뀌는 것이라고 설명할 수 있다.

기존에는 모든 오브젝트가 능동적으로 자신이 사용할 클래스를 결정하고, 언제 어떻게 그 오브젝트를 만들지를 스스로 관장했다. 모든 종류의 작업을 사용하는 쪽에서 제어하는 구조다.  반면 제어의 역전이란 이런 제어 흐름을 거꾸로 뒤집는 것이다. 제어권을 상위 템플릿 메소드에 넘기고, 자신은 필요할 때 호출되어 사용된다는 개념이다.

 Ex) 서블릿의 경우, 서블릿에 대한 제어 권한을 가진 컨테이너가 적절한 시점에 서블릿 클래스의 오브젝트를 만들고 그 안의 메소드를 호출한다.

프레임워크도 제어의 역전이 적용된 대표적인 기술이다. 일단 프레임워크와 라이브러리의 차이를 일단 알아야한다. 

라이브러리를 사용하는 애플리케이션 코드는 애플리케이션 흐름을 직접 제어한다. 동작하는 중에 필요한 기능이 있을 때 능동적으로 라이브러리를 사용할 뿐이다. 반면 프레임 워크는 거꾸로 애플리케이션 코드가 프레임워크에 의해 사용된다. 스프링은 IoC를 모든 기능의 기초가 되는 기반 기술로 삼고 있으며, IoC를 극한까지 적용하고 있는 프레임 워크다.