(2) 스프링을 활용한 DI

 앞서 보았던 순수 자바코드만을 활용한 DI는 한눈에 의존관계를 파악하기 힘들었다. 스프링은 이러한 문제를 해결하기 위해 Bean 컨테이너를 제공한다.

 Bean이란 스프링에서 관리해주는 객체를 의미한다. 만약 어떤 객체가 빈으로 등록되어 있다면, 그 객체를 주입 받을때 스프링 컨테이너에서 자동으로 해주기때문에 편리하다.

 

먼저 주입 객체들을빈으로 등록하자.

 

# Config

@Configuration
public class Config {
    @Bean
    public Alphabet alphabet(){
        return new B();
    }
    
}

@Configuration : 스프링 설정 클래스라는 것을 의미한다. 빈을 수동으로 등록해줄수 있다.

@Bean :  메서드의 반환 객체를 빈으로 등록한다. 빈 이름은 메서드 이름이 된다.

 

이제 테스트 코드로 스프링 컨테이너를 통해 DI를 해보자.

public class TestController {

    @Test
    public void play() {
        // ApplicationContext : 스프링 컨테이너
        // new AnnotationConfigApplicationContext(Config.class) : Config클래스를 포함해, 내부에 @Bean으로
        //                                                        등록된 객체를 컨테이너에 빈으로 등록
        ApplicationContext ac = new AnnotationConfigApplicationContext(Config.class);
        // alphabet 이라는 이름으로 등록된 Alphabet 클래스의 빈을 불러옴
        Alphabet bean = ac.getBean("alphabet", Alphabet.class);
        Controller controller = new Controller(bean);
        controller.mainClassName();
    }
}

#기존 코드

public void play(){
        Config config = new Config();  // Config객체 생성
        Alphabet instance = config.alphabet(); // Config의 alphabetA함수로 만들어진 객체 instance
        Controller controller = new Controller(instance); // Alphabet타입의 구현체를 주입
        controller.mainClassName();
}

 따로 객체를 만들어서 사용자가 직접 DI하지 않고 스프링 컨테이너를 사용하한다.

 

 스프링 컨테이너로 DI를 받으면 여러가지 편리한 점이 존재하는데, 굵직한 것들만 적으면 다음과 같다.

 

1. 빈으로 등록된 객체들은 싱글톤 패턴의 단점을 무시하면서 싱글톤으로 관리된다.

 사용자가 많아져 객체를 무수히 많이 만들게 되면 서버에 큰 부하가 발생하게 됨으로, 싱글톤으로 객체를 다뤄야만 한다. 그런데 개발자가 직접 싱글톤으로 객체를 만들고 사용하려고 하면 OCP원칙을 위반하게 될 가능성이 높을 뿐더러, DIP를 위반하게 되고, 코드의 길이가 길어지게 된다. 결과적으로 유연성이 도리어 떨어지게 된다. 허나 스프링 컨테이너를 사용하면 싱글톤처럼 관리되면서 싱글톤의 모든 문제점을 무시할수 있게 됨으로 매우 편리하다.

 

2. 다양한 기능을 손쉽게 적용시킬수 있다.

 스프링 내부적으로 이미 구현된 다양한 기능들을 간단한 어노테이션이나 상속을 통해 사용가능하다. 덕분에 개발자의 수고가 크게 줄어든다.

 

3. 오류를 파악하기 쉽다.

 스프링은 오랜 역사동안 발전해온만큼 대부분의 오류를 매우 친절하게 알려주며, 같은 이름으로 빈이 2개 이상 등록되는 등, 오류라고 보기 에매한 문제들에 대해서도 고의로 예외를 일으켜 사전에 문제를 방지할수 있도록 한다.