스프링 핵심원리 : 기본편 - IoC, DI, 그리고 컨테이너, 스프링으로 전환

"인프런의 스프링 핵심원리 - 기본편 강의를 듣고 작성한 글 입니다."

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8/dashboard

스프링 핵심 원리 - 기본편 - 인프런 | 강의

제어의 역전(IoC - Inversion of Control)

- 기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성하고, 연결하고, 실행했다. 한 마디로 구현 객체가 프로그램의 제어 흐름을 스스로 조종했다. 개발자 입장에서는 자연스러운 흐름이다.

- 반면에 AppConfig 가 등장한 이후에 구현 객체는 자신의 로직을 실행하는 역할만 담당한다. 프로그램의 제어 흐름은 이제 AppConfig 가 가져간다. 예를 들어 OrderServiceImpl 은 필요한 인터페이스 들을 호출하지만, 어떤 구현 객체들이 실행될지는 모른다.

- 프로그램에 대한 제어 흐름에 대한 권한은 모두 AppConfig 가 가지고 있다. 심지어 OrderServiceImpl 도 AppConfig 가 생성한다. 그리고 AppConfig 는 OrderServiceImpl 이 아닌 OrderService 인터페이스의 다른 구현 객체를 생성하고 실행할 수도 있다. 그런 사실도 모른 체 OrderServiceImpl 은 묵묵히 자신의 로직을 실행할 뿐이다.

- 이렇듯 프로그램의 제어 흐름을 직접 제어하는 것이 아니라, 외부에서 관리하는 것을 제어의 역전(IoC) 이라 한다.

 

+ IoC 는 스프링에만 국한된 것이 아니다. 보통은 개발자가 직접 원하는대로 객체를 생성하고 호출하는 식으로 컨트롤하고 제어하는 스타일로 개발하는데, 제어의 역전은 개발자가 직접 자신이 작성한 코드를 호출하는 것이 아니라, 프레임워크가 개발자 대신 흐름을 제어하는 코드를 실행시켜 주는 개념을 말한다.

말 그대로 제어권이 뒤바뀐다고 하여 제어의 역전 이라고 한다.

 

* 프레임워크 VS 라이브러리

- 프레임워크가 내가 작성한 코드를 제어하고, 대신 실행하면 그것은 프레임워크가 맞다.(예시 : Junit - 작성한 테스트 코드의 실행 권한은 Junit 이 가지고 있다.)

- 반면에 내가 작성한 코드가 직접 제어의 흐름을 담당한다면 그것은 프레임워크가 아니라 라이브러리 이다.

 

의존관계 주입(DI - Dependency Injection)

- OrderServiceImpl 은 DiscountPolicy 인터페이스에 의존한다. 실제 어떤 구현 객체가 사용될지는 모른다.

- 의존관계는 '정적인 클래스 의존관계' 와, 실행 시점에 결정되는 '동적인 객체(인스턴스) 의존관계' 둘을 분리해서 생각해야 한다.

 

* 정적인 의존관계

클래스가 사용하는 import 코드만 보고 의존관계를 쉽게 판단할 수 있다. 정적인 의존관계는 애플리케이션을 실행하지 않아도 분석할 수 있다. 클래스 다이어그램을 한번 보자.

OrderServiceImpl 은 MemberRepository, DiscountPolicy 에 의존한다는 것을 알 수 있다.

그런데 이러한 클래스 의존관계 만으로는 실제 어떤 객체가 OrderServiceImpl 에 주입될지 알 수 없다. (FixDiscountPolicy, RateDiscountPolicy 둘 중에 뭐가 주입될 지 알 수 없다.)

이런 경우는 클래스 의존관계만 보고 의존관계를 파악하는 것이 아니라, 어플리케이션의 실행 시점에 의존관계가 결정 되어진다.

이와 같이 어플리케이션의 실행 시점에 객체간의 의존관계가 결정되는 것을 동적인 객체 인스턴스의 의존관계 라고 한다.

 

* 동적인 객체 인스턴스 의존관계

애플리케이션 실행 시점에 생성된 객체 인스턴스의 참조가 연결되는 의존관계 이다.

- 애플리케이션 실행 시점(런타임) 에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서, 클라이언트와 서버의 실제 의존관계가 연결 되는 것을 의존관계 주입이라고 한다.

- 객체 인스턴스를 생성하고, 그 참조값을 전달해서 연결된다.

- 의존관계 주입을 사용하면 클라이언트 코드를 변경하지 않고, 클라이언트가 호출하는 대상의 타입 인스턴스를 변경할 수 있다.

- 의존관계 주입을 사용하면 정적인 클래스 의존관계를 변경하지 않고, 동적인 객체 인스턴스 의존관계를 쉽게 변경할 수 있다.

 

* IoC 컨테이너, DI 컨테이너

- AppConfig 처럼 객체를 생성하고 관리하면서 의존관계를 연결해주는 것을 IoC 컨테이너, 또는 DI 컨테이너 라고 한다.

- 의존관계 주입에 초점을 맞추어 최근에는 주로 DI 컨테이너 라고 한다.

- 또는 어셈블러, 오브젝트 팩토리 등으로 불리기도 한다.

 

그럼 이제 지금까지 작성했던 예제 코드에 스프링 프레임워크를 적용시켜 보자.

 

지금까지는 순수 자바 코드만으로 DI 를 적용했다. 이제 스프링을 사용해보자.

AppConfig 를 스프링 기반으로 변경한다.

- AppConfig.java

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class AppConfig {
    
    @Bean
    public MemberService memberService(){
        return new MemberServiceImpl(memberRepository());
    }

    @Bean
    public OrderService orderService(){
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }

    @Bean
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }

    @Bean
    public DiscountPolicy discountPolicy() {
//        return new FixDiscountPolicy();
        return new RateDiscountPolicy();
        // 정액 할인 정책 -> 정률 할인 정책으로 변경
    }
}

@Configuration 어노테이션과 @Bean 어노테이션에 대해서는 아래 블로그에 작성된 글에 설명되어 있으니 링크를 참조하자.

https://evan-development.tistory.com/111?category=969786 

스프링 입문 : 코드로 배우는 스프링 부트, 웹 MVC, DB 접근 기술 - 자바 코드로 직접 스프링 빈 등

 

위와 같이 어노테이션을 붙여주면 @Bean 어노테이션이 붙어있는 메소드에서 생성된 객체 인스턴스 들이 모두 스프링 컨테이너에 스프링 빈으로서 등록된다.

그러면 스프링 빈으로서 등록된 객체를 활용해보자.

- MemberApp.java

import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

public class MemberApp {

    public static void main(String[] args) {
//        MemberService memberService = new AppConfig().memberService();

        // 아래의 코드를 통해 스프링이 AppConfig 클래스에 작성되어 있는 @Bean 어노테이션이 붙어있는 메소드를 실행시켜서
        // 해당 객체 인스턴스 들을 스프링 컨테이너에 스프링 빈으로서 등록시켜 준다.
        ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
        // 스프링 빈이 등록될 때 이름은 기본적으로 객체를 생성시킨 메소드 이름으로 저장되므로
        // 아래와 같이 메소드 이름을 통해 MermberService 객체를 가져온다.
        MemberService memberService = applicationContext.getBean("memberService", MemberService.class);

        // 회원 객체 생성 후 가입 요청
        Member member = new Member(1L, "memberA", Grade.VIP);
        memberService.join(member);

        // 가입이 제대로 됐는지 확인
        Member findMember = memberService.findMember(member.getId());

        System.out.println("new member = " + member.getName());
        System.out.println("find Member = " + findMember.getName());

    }
}

- 결과

18:03:59.501 [main] DEBUG org.springframework.context.annotation.AnnotationConfigApplicationContext - Refreshing org.springframework.context.annotation.AnnotationConfigApplicationContext@1ae369b7
18:03:59.520 [main] DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Creating shared instance of singleton bean 'org.springframework.context.annotation.internalConfigurationAnnotationProcessor'
18:03:59.661 [main] DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Creating shared instance of singleton bean 'org.springframework.context.event.internalEventListenerProcessor'
18:03:59.663 [main] DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Creating shared instance of singleton bean 'org.springframework.context.event.internalEventListenerFactory'
18:03:59.664 [main] DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Creating shared instance of singleton bean 'org.springframework.context.annotation.internalAutowiredAnnotationProcessor'
18:03:59.665 [main] DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Creating shared instance of singleton bean 'org.springframework.context.annotation.internalCommonAnnotationProcessor'
18:03:59.675 [main] DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Creating shared instance of singleton bean 'appConfig'
18:03:59.680 [main] DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Creating shared instance of singleton bean 'memberService'
18:03:59.699 [main] DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Creating shared instance of singleton bean 'memberRepository'
18:03:59.700 [main] DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Creating shared instance of singleton bean 'orderService'
18:03:59.701 [main] DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Creating shared instance of singleton bean 'discountPolicy'
new member = memberA
find Member = memberA

종료 코드 0(으)로 완료된 프로세스

위의 코드에서 ApplicationContext 클래스를 통해 만들어진 객체가 스프링 컨테이너 역할을 하게 된다.

여기서 스프링 컨테이너가 만들어질 때 스프링 빈의 등록과, 각 객체간의 의존관계 주입을 위해 작성해둔 AppConfig 를 .class 를 붙여서 클래스 파일 자체를 매개변수로 넘겨 줌으로서, 생성자인 AnnotationConfigApplicationContext 메소드를 실행시켜 생성될 스프링 컨테이너에 미리 작성해둔 AppConfig 상의 설정들을 넘겨준다.

 

이렇게 생성된 스프링 컨테이너에서 스프링 빈 객체를 가져오려면 getBean 메소드를 활용하는데, 매개변수로는 가져오고자 하는 스프링 빈 객체의 이름과, 해당 객체의 반환 타입을 작성해준다.

여기서 가져오고자 하는 스프링 빈 객체의 이름은 AppConfig 에서 해당 객체를 생성할 때 실행되는 메소드의 이름으로 정의되어 있다.

해당 사항은 위에서 보여준 결과 출력 화면에서 다음과 같은 출력 로그를 통해 알 수 있다.

18:03:59.675 [main] DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Creating shared instance of singleton bean 'appConfig'
18:03:59.680 [main] DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Creating shared instance of singleton bean 'memberService'
18:03:59.699 [main] DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Creating shared instance of singleton bean 'memberRepository'
18:03:59.700 [main] DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Creating shared instance of singleton bean 'orderService'
18:03:59.701 [main] DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Creating shared instance of singleton bean 'discountPolicy'

위의 로그를 보면 각 객체들이 스프링 빈으로 등록될 때, 각 객체를 생성하는 메소드의 이름으로 저장되어 있는 것을 확인할 수 있다.(appConfig 까지 포함되어 있다.)

 

그럼 이번엔 OrderApp 도 이와 같이 스프링을 활용하여 코드를 바꿔보자.

- OrderApp.java

public class OrderApp {

    public static void main(String[] args) {
//        MemberService memberService = new AppConfig().memberService();
//        OrderService orderService = new AppConfig().orderService();

        ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService = applicationContext.getBean("memberService", MemberService.class);
        OrderService orderService = applicationContext.getBean("orderService", OrderService.class);

        Long memberId = 1L;
        Member member = new Member(memberId, "memberA", Grade.VIP);
        memberService.join(member);

        Order order = orderService.createOrder(memberId, "itemA", 10000);
        System.out.println("order = " + order.toString());
        System.out.println("order.calculatePrice = " + order.calculatePrice());
    }
}

결과 :

order = Order{memberId=1, itemName='itemA', itemPrice=10000, discountPrice=1000}
order.calculatePrice = 9000

 

스프링 컨테이너

- ApplicationContext를 스프링 컨테이너 라고 한다.

- 기존에는 개발자가 AppConfig 를 사용해서 직접 객체를 생성하고 DI 를 했지만, 이제부터는 스프링 컨테이너를 통해서 사용한다.

- 스프링 컨테이너는 @Configuration 이 붙은 AppConfig 를 설정(구성) 정보로 사용한다. 여기서 @Bean 이라 적힌 메소드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록한다.

이렇게 스프링 컨테이너에 등록된 객체를 스프링 빈이라고 한다.

- 스프링 빈은 @Bean 이 붙은 메소드의 명을 스프링 빈의 이름으로 사용한다.(memberService, orderService) (물론 @Bean 어노테이션의 name 속성을 이용해 이름을 바꿔줄 수도 있다.)

- 이전에는 개발자가 필요한 객체를 AppConfig 를 사용해서 직접 조회했지만, 이제부터는 스프링 컨테이너를 통해서 필요한 스프링 빈(객체) 를 찾아야 한다. 스프링 빈은 applicationContext.getBean() 메소드를 활용해서 찾을 수 있다.

- 기존에는 개발자가 직접 자바 코드로 모든 것을 했다면, 이제부터는 스프링 컨테이너에 객체를 스프링 빈으로 등록하고, 스프링 컨테이너에서 스프링 빈을 찾아서 사용하도록 변경되었다.

 

+ 코드가 약간 더 복잡해진것 같은데, 스프링 컨테이너를 사용하면 어떤 장점이 있을까?

다음 글부터는 스프링에 대해서 좀 더 자세하게 알아보자.