[Spring] 1장 오브젝트와 의존관계(3)

[Spring] 1장 오브젝트와 의존관계(2)

---

[제어의 역전(IoC)]

public class DaoFactory {
    public UserDao usreDao() {
    
        ConnectionMaker connectionMaker = new DConnectionMaker();
        UserDao userDao = new UserDao(connectionMaker);
        //팩토리의 메소드는 UserDao 타입의 오브젝트를 어떻게 만들고, 어떻게 준비시킬지 결정
        return userDao;
    }
}

<UserDao의 생성 책임을 맡은 팩토리 클래스>

이것을 팩토리를 사용 할 수 있도록 수정을 한다면..?!

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

[오브젝트 팩토리의 활용]

오브젝트 생성 코드가 중복이 된다면 좋지 않을수가 있다고 한다. DAO가 더 많아지면 ConnectionMaker의 구현 클래스를 바꿀때마다 모든 메소드를 일일이 수정해야 하기 때문이다.

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 UserDao userDao() {
        return new UserDao(connectionMaker());
    }
    public UserDao userDao() {
        return new UserDao(connectionMaker());
    }
    public ConnectionMaker connectionMaker() {
        return new DConnectionMaker();
        //분리해서 중복을 제거한 ConnectionMaker 타입 오브젝트 생성코드
    }
}

이렇게하면 아무리 DAO가 많아져도 문제가 없고, ConnectionMaker의 구현 클래스를 바꿀 필요가 없음.

 

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

제어역전이란? 간단히 말하자면 프로그램 제어 흐름 구조가 뒤바뀌는 것.

 

[스프링의 IoC]

[오브젝트 팩토리를 이용한 스프링 IoC]

- 스프링에서는 스프링이 제어권을 가지고 직접 만들과 관계를 부여하는 오브젝트를 빈(Bean)이라고 부름. 동시에 스프링 빈은 스프링 컨테이너가 생성과 관계설정, 사용 등을 제어해주는 제어의 역전이 적용된 오브젝트를 가리키는 말

- 스프링에서는 빈의 생성과 관계설정 같은 제어를 담당하는 IoC 오브젝트를 빈 팩토리(bean Factory)라고 부른다. 보통은 이를 더 확장한 애플리케이션 컨텍스트(application context)를 주로 사용.

import java.beans.BeanProperty;
import java.sql.SQLException;


//스프링 빈 팩토리가 사용할 설정정보를 담은 DaoFactory 클래스

@Configuration // 애플리케이션 컨텍스트 또는 빈 팩토리가 사용할 설정정보라는 표시
public class DaoFactory {
    @Bean // 오브젝트 생성을 담당하는 IoC용 메소드라는 표시
    public UserDao userDao() {
        return new UserDao(connectionMaker());
    }
    
    @Bean
    public ConnectionMaker connectionMaker(){
        return new DConecctionMaker();
    }
}

//애플리케이션 컨텍스트를 적용한 UserDaoTest
public class UserDaoTest {
    public static void main(String[] args) throws ClassNotFoundException, SQLException {
        ApplicationContext context = new AnnotationConfigApplicationContext(DaoFactory.class);
        UserDao dao = context.getBean("userDao", UserDao.class);
    }
}

getBean() 메소드는  ApplicationContext가 관리하는 오브젝트를 요청하는 메소드.  getBean()의 파라미터인 userDao는 ApplicationContext에 등록된 빈의 이름. DaoFactory에서 @Bean이라는 애노테이션을 userDao라는 이름의 메소드에 붙였는데, 이 메소드 이름이 바로 빈의 이름이 되는 것.

 

[애플리케이션 컨텍스트의 동작방식]

 

※ DaoFactory를 오브젝트 팩토리로 직접 사용했을 때와 비교해서 애플리케이션 컨텍스트를 사용했을 때 얻을 수 있는 장점

1) 클라이언트는 구체적인 팩토리 클래스를 알 필요 없다.

2) 애플리케이션 컨텍스트는 종합 IoC 서비스를 제공해준다.

3) 애플리케이션 컨텍스트는 빈을 검색하는 다양한 방법을 제공해준다.

 

[스프링 IoC 용어 정리]

 

빈(Bean)

- 빈 또는 빈 오프젝트는 스프링이 IoC 방식으로 관리하는 오브젝트라는 뜻. 주의할점은 스프링을 사용하는 애플리케이션에서  만들어지는 모든 오브젝트가 다 빈은 아니라는거. 그중에서 스프링이 직접 그 생성과 제어를 담당하는 오브젝트만을 빈이라고 부름.

 

빈 팩토리(Bean Factory)

- 스프링의 IoC를 담당하는 핵심 컨테이너. 빈 등록 & 생성 & 조회하고 돌려주고 그 외에 부가적인 빈을 관리하는 기능을 담당. BeanFactory라고 붙여쓰면 빈 팩토리가 구현하고 있는 가장 기본적인 인터페이스 이름이됨.

 

애플리케이션 컨텍스트(Application Context)

- 빈 팩토리를 확장한 IoC 컨테이너. 빈을 등록하고 관리하는 기본적인 기능은 빈 팩토리와 동일.

 

설정정보/ 설정 메타정보(Configuration metadata)

- 스프링 설정정보란 애플리케이션 컨텍스트 또는 빈 빈 팩토리가 IoC를 적용하기 위해 사용하는 메타정보.

 

컨테이너 또는 IoC 컨테이너(Container)

- IoC 방식으로 빈을 관리한다는 의미에서 애플리케이션 컨텍스트나 빈 팩토리를 컨테이너 또는 IoC 컨테이너라고도함.

ex) 스프링에 빈을 등록하고 : 이 경우 스프링이란 말은 스프링 컨테이너 또는 애플리케이션 컨텍스트를 가리키는 말.

 

[싱글톤 레지스트리와 오브젝트 스코프]

[싱글톤 레지스트리로서의 애플리케이션 컨텍스트]

 

※ 싱글톤 패턴 구현 방식의 문제점

1) private 생성자를 갖고 있기 때문에 상속 불가

2) 테스트하기가 힘듬.

3) 서버환경에서는 싱글톤이 하나만 만들어지는 것을 보장하지 못함

4) 싱글톤의 사용은 전역 상태를 만들 수 있기 때문에 바람직하지 못함

 

이러한 단점을 보완하기 위해서 나온것이 싱글톤 레지스트리(Singleton registry)

스태틱 메소드와 private 생성자를 사용해야 하는 비정상적인 클래스가 아니라 평범한 자바 클래스를 싱글톤으로 활용하고 해준다는점. 평범한 자바클라스라도 IoC 방식의 컨테이너를 사용해서 생성과 관계설정, 사용 등에 대한 제어권을 컨테이너에게 모든 권한은 IoC 기능을 제공하는 애플리케이션 컨텍스트에게 있기 때문.

---

출처 : 토비의 스프링 Vol. 1