Spring 핵심원리

이번에는 새로운 할인정책을 적용해봅니다.

새로운 클래스를 만들어서 기존의 DiscountPolicy interface를 implement 합시다

이 때 변경된 할인정책을 적용하려면 OrderServiceImpl 의 discountPolicy를 변경해야한다. 그런데 구체적 구현 클래스를 변경해주고 있다. 추상클래스 혹은 인터페이스에 의존하게 작성해서 OrderServiceImpl에 변경되는 사항이 없도록 하자.

memberRepository 와 discountPolicy 를 생성자를 통해 의존성 주입을 하자.

그리고 실제 실행해줄 app에서 어떤 구현체를 쓸지 넣어주는 AppConfig 파일을 생성한다.

memberService나 orderService를 구현할 때 어떤 구현체를 쓸지 조금더 명확하게 보이도록 하자.

이제 discountPolicy를 변경하고 싶으면 AppConfig 의 discountPolicy()만 바꿔주면 된다.

 

IOC, DI 컨테이너

Inversion of control (제어의 역전) : 각각의 객체는 자신의 실행에 집중하고, 필요하다면 다른 interface를 호출하지만 어떤 구현체일지는 모른다. 즉 프로그램에 대한 제어 흐름이 외부에서 이루어지고 있는 것이다. (이전의 AppConfig)

 

라이브러리와 프레임워크의 차이는 

프레임워크는 내가 작성한 코드를 제어, 사용, 실행한다.

라이브러리는 내가 직접 제어의 흐름을 담당한다.

 

Dependency Injection (의존성 주입) : 정적인 클래스의 의존관계와 실행시점에 결정되는 동적인 객체 의존관계를 분리해서 생각해야한다. 

 

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

 

 

이제 Spring으로 전환해보자.

AppConfig class에 @Configuration Annotation을 붙이고 각 함수마다 @Bean annotation을 통해 빈을 등록한다.

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

이제 ApplicationContext에 등록된 빈을 찾아서 필요한 객체를 조회하면 된다.

 

그럼 ApplicationContext는 두 가지 방식으로 만들 수 있다.

1. XML 기반으로 생성

2. annotation 기반으로 생성

 

스프링 컨테이너는 @Bean annotation이 붙은 객체를 Bean에 등록한다.

스프링 컨테이너는 설정정보를 바탕으로 DI를 한다.

스프링빈에는 ROLE_APPLICATION (사용자 정의) 과 ROLE_INFRASTRUCTURE (스프링 내부에서 사용) 로 나누어진다.

 

그런데 스프링컨테이너는 CGLIB 를 통해 @Configuration annotation이 붙은 클래스를 상속받게 하여 새로운 싱글톤 클래스를 생성해서 스프링 빈에 등록한다.

@Configuration 없이 @Bean만 사용하면 스프링 빈으로 등록은 되지만 싱글톤은 보장하지 않는다.