3. 오브젝트와 의존관계2

9. 스프링 컨테이너와 의존관계 주입(Dependency Injection)

• 스프링 컨테이너는 IoC(Inversion of Control)/DI(Dependency Injection) 기능을 제공하는 컨테이너로 스프링 기술의 핵심이다!

• 우리는 이미 스프링 의존관계 주입을 위한 구조를 만들어두었다. 우리가 만들어 둔 ObjectFactory 가 BeanFactory 로 변경되기만 하면 된다.

• 여기서 빈은 프로그램을 구성하는 오브젝트라고 생각하면 된다.

• 하지만 스프링의 BeanFactory 는 어떤 의존성을 주입해야 하는지 알 수 없다. 때문에 어떤 의존성을 주입해야 하는지 구성정보를 설정하는 ObjectFactory 를 하나 추가해야 한다.

• 여기서 빈은 PaymentService, WebApiExRateProvider 이고, 어떤 의존성을 주입할 것인지에 대한 구성정보를 ObjectFactory 에서 설정하게 된다.

• 아래 코드는 위 구조대로 완벽히 스프링으로 변경되었다.

  • ObjectFactory 에서 BeanFactory 구성정보를 설정해주었다.

  • BeanFactory 를 통해 빈 정보를 가져왔다.

    • 스프링 프레임워크 내부에서 구성정보를 가지고 있는 객체이다.

    • 스프링 컨테이너라고도 부른다.

package spring.hellospringv3;

import org.springframework.beans.factory.BeanFactory;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

import java.io.IOException;
import java.math.BigDecimal;
import java.util.concurrent.TimeUnit;

public class Client {
    public static void main(String[] args) throws IOException, InterruptedException {
        BeanFactory beanFactory = new AnnotationConfigApplicationContext(ObjectFactory.class);
        PaymentService paymentService = beanFactory.getBean(PaymentService.class);

        Payment payment1 = paymentService.prepare(100L, "USD", BigDecimal.valueOf(50.7));
        System.out.println("Payment1 : " + payment1);
    }
}

package spring.hellospringv3;

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

@Configuration
public class ObjectFactory {

    @Bean
    public PaymentService paymentService() {
        return new PaymentService(cachedExRateProvider());
    }

    @Bean
    public ExRateProvider exRateProvider() {
        return new WebApiExRateProvider();
    }
}

의존관계 주입(Dependency Injection)

• IoC 는 스프링의 동작원리를 정확하게 설명하기에는 너무 일반적인 프레임워크 동작원리를 설명하는 용어이다.

• 때문에, 스프링과 같이 오브젝트의 의존관계에 대한 책임을 스프링 컨데이터와 같이 외부 오브젝트가 담당하도록 만드는 것을 설명하는, 의존관계 주입(Dependency Injection) 패턴을 줄여서 DI 라고 불리는 용어가 마틴 파울러에 의해서 제안되었고, 스프링 개발자들 사이 or 이 원칙을 따라서 프레임워크를 만들거나 개발 방식을 설명하는 다른 언어와 기술에서 넓게 사용되고 있다.

• 스프링이 처음 등장했던 시기에는 IoC 라는 용어를 주로 사용했기 때문에, 이후에 DI 를 사용하면서도 IoC 라는 용어도 같이 쓰이기도 한다.

컨테이너

• 애플리케이션을 구성하는 오브젝트를 만들어서 담아두고 필요할 때 사용하도록 제공하는 기능을 담당하는 것을 컨테이너라고 한다.

• 보통 오브젝트를 보관하는 것 뿐 아니라, 생명주기(lifecycle) 까지 담당한다.

• 스프링 컨테이너는 크게 2가지의 동작으로 나뉜다.

  • 첫번째 동작 : 빈 생성

  • 두번째 동작 : 의존관계 설정

10. 구성정보를 가져오는 다른 방법

@Configuration 애노테이션을 활용한 설정파일이 아니라, 빈에 해당하는 클래스에 @Component 를 사용해 구성 정보를 가져올 수 있다.

11. 싱글톤 레지스트리

싱글톤 패턴(Singleton Pattern)

• 싱글톤 패턴은 어떤 클래스 애플리케이션 내에서 제한된 인스턴스 개수, 이름처럼 주로 하나만 존재하도록 강제하는 패턴이다. 이렇게 하나만 만들어지는 클래스의 오브젝트는 애플리케이션 내에서 전역적으로 접근이 가능하다. 이를 애플리케이션의 여러 곳에서 공유하는 경우에 주로 사용한다.

• 싱글톤 패턴은 GoF 가 소개한 디자인패턴 중 하나이다. 디자인 패턴 중에서 가장 자주 활용되는 패턴이기도 하지만, 가장 많은 비판을 갖는 패턴이기도 하다. 심지어 디자인 패턴은 쓴 GoF 멤버조차도 싱글톤 패턴은 매우 조심해서 사용해야 하거나, 피해야 할 패턴이라고 말하기도 한다.

싱글톤 패턴의 단점

• private 생성자를 가지고 있어 상속할 수 없다.

• 싱글톤은 테스트하기 힘들다.

• 서버 환경에서는 싱글톤이 하나만 만들어지는 것을 보장하지 못한다. (?)

  • 멀티 프로세스 환경에서는 싱글톤이더라도 각 프로세스마다 인스턴스를 갖게 된다.

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

  • 전역 상태라는 것은 예상치 못한 곳에서 변경이 일어날 위험이 있다는 것이다!

싱글톤 레지스트리

• 스프링은 하나의 오브젝트만 만들어져야 한다는 필요를 충족하면서도 싱글톤 패턴을 사용해서 만들어졌을 때의 단점을 가지지 않도록 코드 레벨이 아닌 컨테이너 레벨에서 하나의 오브젝트만 만들어지는 것을 보장하는 기능(CGLIB 라이브러리 사용)을 제공한다.

• 이렇게 싱글톤 오브젝트를 만들고 관리하는 스프링 컨테이너를 싱글톤으로 등록하고 관리한다는 의미에서 싱글톤 레지스트리라고 말한다.

• 스프링 빈이 생성되고 적용되는 범위를 빈 스코프(scope) 라고 부른다. 스프링은 기본적으로 빈 오브젝트가 싱글톤 스코프를 가지도록 한다. 필요에 따라 스코프가 다른(prototype, request, ...) 빈 오브젝트가 만들어지도록 할 수 있다.

12. DI 와 디자인패턴

• 디자인 패턴을 구분하는 두 가지 방식이 있는데, 하나는 사용 목적(purpose) 이고, 하나는 스코프(scope) 이다.

• 스코프에 의해서 분류하면 클래스 패턴과, 오브젝트 패턴으로 나눌 수 있다.

  • 클래스 패턴 : 상속을 사용해서 확장성을 가진 패턴으로 만든다. (상속을 하는 것 자체에 제약이 많기 때문에, 오브젝트 패턴을 사용하는 디자인 패턴이 많다)

  • 오브젝트 패턴 : 합성을 사용한다.

• 합성을 이용하는 디자인 패턴을 적용할 때, 스프링의 의존관계 주입(DI) 를 사용한다고 생각하면 된다.

• PaymentService 에서도 오브젝트 합성을 이용하는 전략 패턴을 확인할 수 있다.

데코레이터 패턴(Decorator Pattern)

우리가 만든 예제에서 새로운 요구사항이 들어왔다.

• 응답 속도를 줄이기 위해서 매 요청마다 환율정보를 가져오는 것이 아니라,

• 한번 가져온 환율정보를 재사용한다.

이를 데코레이터 패턴을 사용해서 추가해보자.

• 데코레이터 패턴 : 오브젝트에 부가적인 기능 / 책임을 동적으로 부여하는 디자인 패턴이다.

• Client 입장에서는 PaymentService 코드에서 변경사항이 있는 알지 못한다. (알 필요도 없다!)

• ObjectFactory 는 예외이다! 구성이 바뀌는 것이기 때문에, 변경이 있을 수 있다.

package spring.hellospringv3;

import java.io.IOException;
import java.math.BigDecimal;
import java.time.LocalDateTime;

public class CachedExRateProvider implements ExRateProvider{
    private final ExRateProvider target;

    private BigDecimal cachedExRate;
    private LocalDateTime cacheExpiryTime;

    public CachedExRateProvider(ExRateProvider target) {
        this.target = target;
    }

    @Override
    public BigDecimal getExRate(String currency) throws IOException {
        if(cachedExRate == null || cacheExpiryTime.isBefore(LocalDateTime.now())) {
            cachedExRate = target.getExRate(currency);
            cacheExpiryTime = LocalDateTime.now().plusSeconds(3);

            System.out.println("Cache Updated");
        }

        return cachedExRate;
    }
}

package spring.hellospringv3;

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

@Configuration
public class ObjectFactory {

    @Bean
    public PaymentService paymentService() {
        return new PaymentService(cachedExRateProvider());
    }

    @Bean
    public ExRateProvider cachedExRateProvider() {
        return new CachedExRateProvider(exRateProvider());
    }

    @Bean
    public ExRateProvider exRateProvider() {
        return new WebApiExRateProvider();
    }
}

package spring.hellospringv3;

import org.springframework.beans.factory.BeanFactory;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

import java.io.IOException;
import java.math.BigDecimal;
import java.util.concurrent.TimeUnit;

public class Client {
    public static void main(String[] args) throws IOException, InterruptedException {
        BeanFactory beanFactory = new AnnotationConfigApplicationContext(ObjectFactory.class);
        PaymentService paymentService = beanFactory.getBean(PaymentService.class);

        Payment payment1 = paymentService.prepare(100L, "USD", BigDecimal.valueOf(50.7));
        System.out.println("Payment1 : " + payment1);
        System.out.println("==========================");

        Payment payment2 = paymentService.prepare(100L, "USD", BigDecimal.valueOf(50.7));
        System.out.println("Payment2 : " + payment2);
        System.out.println("==========================");

        TimeUnit.SECONDS.sleep(4);

        Payment payment3 = paymentService.prepare(100L, "USD", BigDecimal.valueOf(50.7));
        System.out.println("Payment3 : " + payment3);

    }
}

13. 의존성 역전 원칙(Dependency Inversion Principle)

의존성 역전 원칙(DIP)

1. 상위 수준의 모듈은 하위 수준의 모듈에 의존해서는 안된다. 둘 모두 추상화에 의존해야 한다.

   1. 모듈 : 전체 소프트웨어 시스템을 작은 단위로 쪼개 놓은 것을 의미한다. Ex) .jar, 패키지로 구분된 코드

2. 추상화는 구체적인 사항의 의존해서는 안된다. 구체적인 사항은 추상화에 의존해야 한다.

현재 우리 코드에서는 아래와 같이 모듈을 나누어 볼 수 있다.

• Policy Layer : 서비스 동작과 관련된 모듈

  • Payment.java

  • PaymentService.java

• Mechanism Layer : 세부 정책과 관련된 모듈

  • ExRateDate.java

  • ExRateProvider.java

  • WebApiExRateProvider.java

  • SimpleExRateProvider.java

  • CachedExRateProvider.java

위에서 나눈 분류대로 모듈(패키지) 로 나누어보자.

그렇다면 정말 DIP 의 모든 요구사항을 지키고 있는가?

• 현재 우리 코드는 추상화에 의존하고 있다.

• 하지만, 여전히 상위 모듈(PaymentService)이 하위 수준의 모듈(ExRateProvider)을 의존하고 있다..

• 때문에, 의존성 역전 원칙을 지킨다고 볼 수 없다!

Separated Interface 패턴

여전히 위 그림에서는 상위 모듈이 하위 모듈을 의존하고 있다. 때문에, 인터페이스 소유권의 역전이 필요하다.

어떻게 하면 될까?

• 간단하다. ExRateProvider 파일을 상위 모듈로 패키지를 옮겨주면 된다.

• 의존하고 있는 파일의 위치를 상위 모듈로 옮겨주면 된다.

• 파일 위치를 변경하고 아래와 같이 그림이 바뀐 것을 확인할 수 있다.