🌱 스프링 원리 (기본)

✔️ 스프링 핵심원리 이해2 - 객체 지향 원리 적용

다형성을 고려해서 인터페이스와 객체를 구분하여 코드를 구현했지만 객체를 갈아끼우는 과정에서 DIP와 OCP가 지켜지지않는 문제가 생긴다. 이 문제를 해결하기 위한 과정을 코드를 통해 이해하는 챕터

→ 개방 폐쇄 원칙인 OCP(확장에는 열려있어야 하지만 변경에는 닫혀 있어야 한다.)와 의존 역전 원칙인 DIP(객체는 고차원의 모듈에만 의존할 뿐 저차원의 모듈에 대해서 의존해서는 안된다)를 지키기 위해서 AppConfig를 사용해 의존 관계 주입을 해준다.

• AppConfig 애플리케이션의 전체 동작 방식을 구성하기 위해 구현 객체를 생성하고, 연결하는 책임을 가지는 별도의 설정 클래스 AppConfig에서 각 구현 객체를 생성하며 이를 생성자를 통해 주입시켜준다(생성자 주입) 이에 따라 구현 클래스들은 구현체에 의존하지 않으며 어떤 구현 객체를 주입할지는 오직 외부에서 결정된다.
  

좋은 객체 지향 설계의 5가지 원칙 적용 SOLID

• SRP 단일 책임 원칙 - 한 클래스는 하나의 책임만 가져야 한다.
  • 구현 객체를 생성하고 연결하는 책임은 AppConfig가 담당
  • 클라이언트 객체는 실행하는 책임만 담당
• DIP 의존관계 역전 원칙 - 추상화에 의존해야지, 구체화에 의존하면 안된다.
  • AppConfig가 객체 인스턴스를 클라이언트 코드 대신 생성해서 클라이언트 코드에 의존관계를 주입 ( 생성자 주입 )
• OCP 개방 폐쇄 원칙 - 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
  • 다형성을 사용하고 클라이언트가 DIP를 지킴
  • 애플리케이션을 사용영역과 구성영역으로 나눔
  • 소프트웨어 요소를 새롭게 확장해도 사용 영역의 변경은 닫혀 있다.

IoC, DI, 컨테이너

• IoC (Inversion of Control) 제어의 역전
  • 기존의 프로그램에서는 클라이언트 코드에서 객체의 생성과 주입을 관리하는게 일반적이었다. 하지만 DIP와 OCP가 지켜지지 않는 문제가 있어 제어의 흐름을 AppConfig에게 전임해 이 DI컨테이너가 객체의 생성과 연결, 즉 애플리케이션의 전체 구성을 관리한다.
  • 이렇듯 제어의 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전이라고 한다.
• DI (Dependency Injection)
  • 정적인 클래스 의존 관계와 동적인 객체 인스턴스 의존관계
    • 정적인 클래스 의존관계는 해당 클래스의 Import 내역들을 보면 파악할 수 있다.
    • 동적인 객체 인스턴스 의존관계는 애플리케이션 실행 시점(런타임)에 객체가 생성, 참조가 연결된 의존관계이다
  • 애플리케이션 실행 시점(런타임)에 외부에서 객체 인스턴스를 생성하고 클라이언트에 전달하여 클라이언트와 서버의 실제 의존관계가 연결되는 것을 의존관계 주입이라고 한다.
  • 의존관계 주입을 사용하면 정적인 클래스 의존관계를 수정하지 않고 쉽게 동적인 객체 인스턴스 의존관계를 변경할 수 있다.

✔️ 스프링 컨테이너와 스프링 빈

스프링 적용

1. AppConfig 클래스에 @Configuration Annotation을 붙이고 각 메서드에 @Bean Annotation을 붙인다.
2. 이전에는 필요한 객체를 부를 때 AppConfig를 선언해 직접 불러왔지만 이제는 스프링 컨테이너를 이용해서 필요한 스프링 빈(객체)를 찾아야 한다.

//AppConfig appConfig = new AppConfig();
//MemberService memberService = appConfig.memberService();

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

• ApplicationContext를 스프링 컨테이너라고 한다.
• AnnotationConfigApplicationContext는 ApplicationContext 인터페이스의 구현체이다.

스프링 빈 조회

• 예제코드

  package hello.core.beanfind;
  
  import hello.core.discount.DiscountPolicy;
  import hello.core.discount.FixDiscountPolicy;
  import hello.core.discount.RateDiscountPolicy;
  import org.junit.jupiter.api.Assertions;
  import org.junit.jupiter.api.DisplayName;
  import org.junit.jupiter.api.Test;
  import org.springframework.beans.factory.NoUniqueBeanDefinitionException;
  import org.springframework.context.annotation.AnnotationConfigApplicationContext;
  import org.springframework.context.annotation.Bean;
  import org.springframework.context.annotation.Configuration;
  
  import java.util.Map;
  
  public class ApplicationContextExtendsFindTest {
  
      AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class);
  
      @Test
      @DisplayName("부모 타입으로 조회시, 자식이 둘 이상 있으면, 중복 오류가 발생한다.")
      void findBeanByParentTypeDuplicate(){
          Assertions.assertThrows(NoUniqueBeanDefinitionException.class,
                  () -> ac.getBean(DiscountPolicy.class));
      }
  
      @Test
      @DisplayName("부모 타입으로 조회시, 자식이 둘 이상 있으면, 빈 이름을 지정하면 된다.")
      void findByParentTypeBeanName() {
          DiscountPolicy bean = ac.getBean("RateDiscountPolicy",DiscountPolicy.class);
          org.assertj.core.api.Assertions.assertThat(bean).isInstanceOf(RateDiscountPolicy.class);
      }
  
      @Test
      @DisplayName("특정 하위 타입으로 조회")
      void findBeanBySubType(){
          RateDiscountPolicy bean = ac.getBean(RateDiscountPolicy.class);
          org.assertj.core.api.Assertions.assertThat(bean).isInstanceOf(RateDiscountPolicy.class);
      }
  
      @Test
      @DisplayName("부모 타입으로 모두 조회하기")
      void findBeanByParentType() {
          Map<String, DiscountPolicy> beansOfType = ac.getBeansOfType(DiscountPolicy.class);
          org.assertj.core.api.Assertions.assertThat(beansOfType.size()).isEqualTo(2);
          for (String key : beansOfType.keySet()) {
              System.out.println("key = " + key + " value = " + beansOfType.get(key));
          }
      }
  
      @Test
      @DisplayName("부모 타입으로 모두 조회하기 - Object")
      void findAllBeanByObjectType() {
          Map<String, Object> beansOfType = ac.getBeansOfType(Object.class);
          for (String key : beansOfType.keySet()) {
              System.out.println("key = " + key + " value = " + beansOfType.get(key));
          }
      }
  
      @Configuration
      static class TestConfig{
  
          @Bean
          public DiscountPolicy RateDiscountPolicy(){
              return new RateDiscountPolicy();
          }
  
          @Bean
          public DiscountPolicy FixDiscountPolicy(){
              return new FixDiscountPolicy();
          }
      }
  }

※ static 을 붙이지 않은 inner class는 outer class에 종속된다. 이런 경우 outer class의 객체를 선언한 후 inner class를 사용할 수 있다. 하지만 static을 붙일 경우 inner class임에도 불구하고 독립적인 객체로 선언이 가능하다. → Static inner class는 해당 outer class 내에서 선언하여 이용하려는 경우 사용

BeanFactory와 ApplicationContext

• BeanFactory
  • 스프링 컨테이너의 최상위 인터페이스
  • 스프링 빈을 관리하고 조회하는 역할을 담당
• ApplicationContext
  • BeanFactory의 기능을 모두 상속받는다
  • 애플리케이션 개발에 필요한 부가기능들이 Extends 되어있다.
    • 메시지 소스를 활용한 국제화 기능
    • 환경변수
    • 애플리케이션 이벤트 - 이벤트를 발행하고 구독하는 모델을 편리하게 조회
    • 편리한 리소스 조회 - 파일, 클래스패스, 외부 등에서 리소스를 편리하게 조회

BeanDefinition

• 스프링은 다양한 형태의 설정 정보를 BeanDefinition으로 추상화해서 사용한다.

✔️ 싱글톤 패턴

• 클래스의 인스턴스가 1개만 생성되도록 보장하는 디자인 패턴
• 싱글톤 패턴을 사용하지 않고 유저의 요청이 있을 때마다 인스턴스를 생성한다면 메모리 효율성이 떨어지게 된다.

스프링을 사용하지 않고 싱글톤 패턴 만들기

package hello.core.singleton;
public class SingletonService {
 //1. static 영역에 객체를 딱 1개만 생성해둔다.
 private static final SingletonService instance = new SingletonService();
 //2. public으로 열어서 객체 인스턴스가 필요하면 이 static 메서드를 통해서만 조회하도록
허용한다.
 public static SingletonService getInstance() {
 return instance;
 }
 //3. 생성자를 private으로 선언해서 외부에서 new 키워드를 사용한 객체 생성을 못하게 막는다.
 private SingletonService() {
 }
 public void logic() {
 System.out.println("싱글톤 객체 로직 호출");
 }

• 싱글톤 패턴을 구현하는 방법은 여러가지이다. 여기서 사용한 방법은 객체를 미리 생성해두는 가장 안전하고 단순한 방법이다.
• 스프링을 사용하지 않고 싱글톤 패턴을 사용할 경우 다음과 같은 문제점들이 있다.
  • 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.
  • 의존관계상 클라이언트가 구체 클래스에 의존한다. DIP를 위반한다.
  • 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다.
  • 테스트하기 어렵다.
  • 내부 속성을 변경하거나 초기화 하기 어렵다.
  • private 생성자로 자식 클래스를 만들기 어렵다.
  • 결론적으로 유연성이 떨어진다.
  • 안티패턴으로 불리기도 한다

스프링 컨테이너 (→ 싱글톤 컨테이너)

• 스프링 컨테이너 (ApplicationContext or AnnotationConfigApplicationContext)를 사용하면 위와 같은 코드가 필요없이 자동으로 싱글톤으로 관리된다.
• 싱글톤 패턴을 위한 지저분한 코드가 들어가지 않아도 된다.
• DIP, OCP, 테스트, private 생성자로 부터 자유롭게 싱글톤을 사용할 수 있다.

싱글톤 방식의 주의점

• 싱글톤 방식은 여러 클라이언트가 하나의 객체를 공유하기 때문에 싱글톤 객체는 상태를 유지(Stateful)하게 설계하면 안된다.
• 무상태로 설계해야한다!!
  • 특정 클라이언트에 의존적인 필드가 있으면 안된다.
  • 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다!
  • 가급적 읽기만 가능해야 한다.
  • 필드 대신에 자바에서 공유되지 않는, 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.

공유필드를 조심하고 항상 무상태로 설계하자!

@Configuration과 싱글톤

• @Configuration 를 붙이면 바이트 코드를 조작하는 라이브러리인 CGLIB을 사용하여 내가 만든 AppConfig를 상속받은 임의의 자식 클래스를 만들고, 그 클래스를 스프링 빈으로 등록한다.
• 이 임의의 자식 클래스가 싱글톤을 보장해준다.

✔️ 컴포넌트 스캔

컴포넌트 스캔, 의존관계 자동 주입

• 지금까지는 자바코드에 Bean Annotation 또는 XML파일의 을 사용해 스프링 빈을 등록해주었다. 하지만 스프링 빈의 개수가 많아짐에 따라 일일이 등록하기에는 효율성이 떨어진다. → 그래서 스프링은 설정정보 없이도 자동으로 스프링 빈을 등록해주는 컴포넌트 스캔이라는 기능을 제공한다. 또한 의존관계 또한 자동으로 주입해주는 @Autowired 라는 기능을 제공한다.
  

1. 설정 정보에 @ComponentScan을 붙여준다.
2. 스프링 빈으로 등록하고 싶은 클래스에 @Component 를 붙여준다
3. 의존관계 주입을 위해 해당 클래스의 생성자에 @Autowired 를 붙여준다.

※ @Configuration 소스코드를 열어보면 @Component Annotation이 붙어있기 때문에 @Configuration 또한 컴포넌트 스캔의 대상이 된다. 이를 막기 위해서는 다음과 같이 설정해주면 된다.

@ComponentScan(
        excludeFilters = @ComponentScan.Filter(type = FilterType.ANNOTATION, classes = Configuration.class)
)
public class AutoAppConfig {
}

• @ComponentScan

  • @Component가 붙은 클래스를 스프링 빈으로 등록하는데 이때 스프링 빈의 이름은 클래스명을 사용하되 맨 앞글자만 소문자를 사용한다.
  • 빈 이름 직접 지정: @Component("memberService2")
  • 모든 자바 클래스들을 컴포넌트 스캔하면 시간이 오래 걸리기 때문에 필요한 위치부터 탐색하도록 시작 위치를 지정 할 수 있다

    @ComponentScan(
    		basePackages = "hello.core", // {"hello.core", "hello.service"} 여러 위치 지정
    )

  • basePackageClasses : 지정한 클래스의 패키지를 탐색 시작 위치로 지정
  • Default : @ComponentScan이 붙은 설정 정보 클래스의 패키지가 시작 위치

• @Autowired

  • @Autowired 지정시 스프링 컨테이너가 자동으로 타입이 같은 빈을 찾아서 주입해준다.

• Component Annotation이 있는 Annotation들의 기능

  • @Controller : 스프링 MVC 컨트롤러로 인식
  • @Repository : 스프링 데이터 접근 계층으로 인식, 데이터 계층의 예외를 스프링 예외로 변환 → DB의 변경을 자유롭게 하기 위해
  • @Configuration : 스프링 설정 정보로 인식, 스프링 빈이 싱글톤을 유지하도록 처리
  • @Service : 개발자들이 비즈니스 계층을 인식하는데 도움이 된다.

스프링 빈 중복 등록

1. 자동 빈 등록 vs 자동 빈 등록
   • 스프링에서 ConflictingBeanDefinitionException 예외 발생
2. 수동 빈 등록 vs 자동 빈 등록
   • 수동 빈이 자동 빈을 오버라이딩하기 때문에 수동 빈이 우선 순위를 가진다.
   • 하지만 스프링 부트에서는 오류가 나도록 기본 값을 설정해두었다.
   • application.properties 파일에 오류발생이 나오는 로그인 spring.main.allow-bean-definition-overriding=true 를 추가하면 오류가 나지않고 오버라이딩이 되도록 설정할 수 있다.

필터

• 컴포넌트 스캔의 대상을 추가, 제외 시킨다.

@Configuration
    @ComponentScan(
            includeFilters = @ComponentScan.Filter(type = FilterType.ANNOTATION, classes = MyIncludeComponent.class),
            excludeFilters = @ComponentScan.Filter(type = FilterType.ANNOTATION, classes = MyExcludeComponent.class)
    )
    static class ComponentFilterAppConfig{
    }

• IncludeFilter로 사용할 Annotation과 ExcludeFilter로 사용할 Annotation를 각각 선언한 후 제외 또는 추가하고 싶은 클래스에 해당 어노테이션을 붙인다.

  @Target(ElementType.TYPE)
  @Retention(RetentionPolicy.RUNTIME)
  @Documented
  public @interface MyIncludeComponent {
  }

✔️ 의존관계 자동 주입

다양한 의존관계 주입 방법

• 생성자 주입
  • 생성자 호출 시점에 딱 1번만 호출되는 것이 보장
  • 불변, 필수 의존관계에 사용
  • ※ 생성자가 1개일 경우 @Autowired를 생략해도 자동 주입
• 수정자 주입 (Setter 주입)

  • 수정자(Setter) 메서드를 통해 의존관계를 주입하는 방법

  • 선택, 변경 가능성이 있는 의존관계에 사용

  • @Autowired의 기본동작은 주입할 대상이 없으면 오류를 발생시킨다. 대상이 없어도 동작하게 하기 위해서는 @Autowired(required=false)

    private MemberRepository memberRepository;
    @Autowired
    public void setMemberRepository(MemberRepository memberRepository){
    			this.memberRepository = memberRepository;
    }

• 필드 주입
  • 코드가 간결하지만 외부에서 변경이 불가능하여 테스트하기가 어렵다.
  • DI 프레임워크가 없으면 아무것도 할 수 없다. → 스프링 컨테이너를 사용하지 않은 순수 자바코드로는 테스트가 불가능하다. 가능하게 하기 위해서는 Setter 메서드를 따로 선언해주어야 한다.
    
• 일반 메서드 주입
  • 잘 사용하지 않는다.

Autowired 옵션 처리

• @Autowired(required=false) : 자동 주입할 대상이 없으면 수정자 메서드가 호출되지 않는다.
• @Nullable : 자동 주입할 대상이 없으면 null이 입력된다.
• Optional<> : 자동 주입할 대상이 없으면 Optional.empty가 입력된다.

생성자 주입을 선택해라!

• 불변
  • 대부분의 의존관계 주입은 한번 일어나면 애플리케이션 종료시점까지 의존관계를 변경할 일이 없다.
  • 수정자 주입을 위해서는 set 메서드를 열어두어야 하는데, 변경하면 안되는 메서드를 열어두는 것은 좋은 설계 방법이 아니다.
• 수정자 주입을 한 상태에서 순수한 자바 코드를 단위 테스트 하는 경우 컴파일 오류가 발생한다.
• final 키워드를 사용해 컴파일 오류를 일으킬 수 있다.
  • 컴파일 오류는 세상에서 가장 빠르고, 좋은 오류다!

롬복과 최신 트렌드

• 롬복 라이브러리 적용 방법 build.gradle 에 라이브러리 및 환경 추가

  
  plugins {
  id 'org.springframework.boot' version '2.3.2.RELEASE'
  id 'io.spring.dependency-management' version '1.0.9.RELEASE'
  id 'java'
  }
  group = 'hello'
  version = '0.0.1-SNAPSHOT'
  sourceCompatibility = '11'
  //lombok 설정 추가 시작
  configurations {
  compileOnly {
  extendsFrom annotationProcessor
  }
  }
  //lombok 설정 추가 끝
  repositories {
  mavenCentral()
  }
  dependencies {
  implementation 'org.springframework.boot:spring-boot-starter'
  
  //lombok 라이브러리 추가 시작
  compileOnly 'org.projectlombok:lombok'
  annotationProcessor 'org.projectlombok:lombok'
  testCompileOnly 'org.projectlombok:lombok'
  testAnnotationProcessor 'org.projectlombok:lombok'
  //lombok 라이브러리 추가 끝
  
  testImplementation('org.springframework.boot:spring-boot-starter-test') {
  exclude group: 'org.junit.vintage', module: 'junit-vintage-engine'
  }
  }
  test {
  useJUnitPlatform()
  }

  1. Preferences(윈도우 File Settings) plugin lombok 검색 설치 실행 (재시작)
  2. Preferences Annotation Processors 검색 Enable annotation processing 체크 (재시작)
  3. 임의의 테스트 클래스를 만들고 @Getter, @Setter 확인
• 롬복 라이브러리가 제공하는 @RequiredArgsConstructor Annotation을 사용하면 롬복이 자바의 애노테이션 프로세서라는 기능을 이용해서 컴파일 시점에 final이 붙은 필드를 모아서 생성자를 자동으로 만들어준다.

의존관계 주입 시 조회 빈이 2개 이상일 경우 - @Autowired 필드명 , @Qualifier, @Primary

• 문제 상황
  • @Autowired는 타입으로 조회 → ac.getBean(DiscountPolicy.class) 와 유사하게 동작
  • DiscountPolicy를 통해 구체화된 빈이 두개 이상 있을 경우 의존관계 자동 주입 시 NoUniqueBeanDefinitionException 오류 발생
  • 하위 타입(구체화 타입)을 지정할 수도 있지만 DIP를 위배하고 유연성이 떨어진다.
• 해결 방법
  • Autowired 필드 명 매칭
    • Autowired는 타입 매칭을 시도하고, 이 때 여러 빈이 있을 경우 필드 이름, 파라미터 이름으로 빈 이름을 추가 매칭한다. → 필드 이름이나 파라미터 이름을 주입하고 싶은 클래스 이름과 똑같이 설정한다면 해당 클래스로 매칭된다.
      
  • @Qualifier

    1. 빈 등록시 @Qualifier를 붙여준다.

       @Component
       @Qualifier("mainDiscountPolicy")
       public class RateDiscountPolicy implements DiscountPolicy {}

    2. 주입 시에 @Qualifier를 붙여주고 등록한 이름을 적어준다.

       @Autowired
       public OrderServiceImpl(MemberRepository memberRepository, 
       									@Qualifier("mainDiscountPolicy") DiscountPolicy discountPolicy) {
       		this.memberRepository = memberRepository;
       		this.discountPolicy = discountPolicy;
       }

  • @Primary
    • @Primary Annotation이 붙은 클래스가 우선권을 가진다.
  • Qualifier와 Primary 중 Qualifier가 우선순위가 높다.

Annotation 만들기

@Target({ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER, ElementType.TYPE, ElementType.ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
@Qualifier("mainDiscountPolicy")
public @interface MainDiscountPolicy {
}

조회한 빈이 모두 필요할 때 List, Map

예) 할인 서비스를 제공하는데, 클라이언트가 할인의 종류를 선택할 수 있도록 하는 경우

• 코드 보고 이해하기!!

  public class AllBeanTest {
  
      @Test
      void findAllBean() {
          AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AutoAppConfig.class, DiscountService.class);
          DiscountService discountService = ac.getBean(DiscountService.class);
          Member member = new Member(1L, "name", Grade.VIP);
          int discountPrice = discountService.discount(member, 10000, "fixDiscountPolicy");
  
          Assertions.assertThat(discountPrice).isEqualTo(1000);
  
          int rateDiscountPrice = discountService.discount(member, 20000, "rateDiscountPolicy");
  
          Assertions.assertThat(rateDiscountPrice).isEqualTo(2000);
      }
  
      static class DiscountService {
          private final Map<String, DiscountPolicy> policyMap;
          private final List<DiscountPolicy> policies;
  
          @Autowired
          public DiscountService(Map<String, DiscountPolicy> policyMap, List<DiscountPolicy> policies) {
              this.policyMap = policyMap;
              this.policies = policies;
              System.out.println("policyMap = " + policyMap);
              System.out.println("policies = " + policies);
          }
  
          public int discount(Member member, int price, String discountCode) {
              DiscountPolicy discountPolicy = policyMap.get(discountCode);
              return discountPolicy.discount(member, price);
          }
      }
  }

실무에서의 자동, 수동 등록

• 편리한 자동 기능을 기본으로 사용
• 웹을 지원하는 컨트롤러, 핵심 비즈니스 로직이 있는 서비스, 리포지토리 등의 업무로직 빈은 자동 등록, 기술적인 문제나 공통 관심사(AOP)를 처리할 때 주로 사용되는 기술 지원 빈은 수동 등록
• 비즈니스 로직 중에 다형성을 적극 활용할 때 (예 →조회한 빈이 모두 필요할 때)는 수동등록을 고민해보자 - 자동 등록 시 구현 객체가 한눈에 드러나지 않기 때문에, 그래도 자동등록을 사용하고 싶을 경우 같은 추상화 객체를 사용한 구현체는 같은 패키지에 묶어두자

✔️ 빈 생명주기 콜백

• 스프링 빈의 이벤트 라이프 사이클 스프링 컨테이너 생성 → 스프링 빈 생성 → 의존관계 주입 → 초기화 콜백 → 사용 → 소멸전 콜백 → 스프링 종료
  
• 스프링 빈은 객체를 생성하고 의존관계 주입을 끝내고 나서야 필요한 데이터를 사용할 수 있는 준비가 완료된다. 따라서 초기화 작업은 의존관계 주입이 끝나고 나서 실행되어야한다.
• 그러기 위해서는 개발자가 초기화 콜백 시점을 알아야한다.

객체의 생성과 초기화를 분리하자

생성자에 초기화 코드를 넣으면 되지 않을까라는 생각을 할 수 있다. 하지만 생성자는 필수정보(파라미터)를 받고 객체를 생성하는 책임을 가지며, 초기화는 이렇게 생성된 값들을 활용하여 외부 커넥션을 연결하는 등의 무거운 작업을 수행한다.

따라서 생성자 안에서 무거운 초기화 작업을 함께하는 것보다 나누는 것이 유지보수 관점에서 더 나을 수 있다.

콜백 시점을 아는 방법 3가지

1. 인터페이스 InitializingBean, DisposableBean

• 클래스에 InitializingBean, DisposableBean을 Implements해서 메서드를 오버라이딩한 후 실행하고 싶은 코드를 각 메서드 안에 넣는다.
• 단점
  • 스프링 전용 인터페이스에 의존한다.
  • 초기화, 소멸 메서드의 이름을 변경할 수 없다
  • 내가 코드를 고칠 수 없는 외부 라이브러리에 적용할 수 없다.

2. 빈 등록 초기화, 소멸 메서드 지정

• 설정 정보에 Bean(initMethod= "init", destroyMethod= "close") 처럼 초기화, 소멸 메서드를 지정할 수 있다.
• 특징
  • 메서드 이름을 자유롭게 줄 수 있다.
  • 스프링 빈이 스프링 코드에 의존하지 않는다.
  • 외부 라이브러리에도 초기화, 소멸 메서드를 적용할 수 있다.
• 종료 메서드 추론
  • 외부 라이브러리는 대부분 close , shutdown 이라는 이름의 종료 메서드를 사용한다.
  • @Bean의 destoryMethod 는 기본값이 (inferred) 로 등록되어 있는데 이는 close, shutdown 이라는 이름의 메서드를 자동으로 호출 해준다.

3. Annotation @PostConstruct, @PreDestroy

• 초기화, 소멸 메서드에 해당 Annotation을 붙이면 된다.
• 스프링에 종속적인 기술이 아니라 자바 표준 → 스프링이 아닌 다른 컨테이너에서도 동작
• 코드를 고칠 수 없는 외부라이브러리에는 적용할 수 없다. → 2번 방법 사용

✔️ 빈 스코프

• 빈 스코프는 말 그래로 빈이 존재할 수 있는 범위(기간)를 의미한다

스코프 지정 방법

@Scope("singleton") , @Scope("prototype") 과 같이 Annotation을 붙여주면 된다. 컴포넌트 스캔 사용시 해당 클래스에, Bean Annotation을 사용한 수동주입 시 Bean Annotation에.

스프링이 지원하는 스코프

• 싱글톤: 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프
• 프로토타입: 프로토타입 빈의 생성과 의존관계 주입, 초기화까지만 관리하고 더는 관리하지 않는 스코프(의존관계 주입이 끝나는 동시에 컨테이너밖으로 던져버린다.)
  • 요청이 올 때마다 항상 새로운 프로토타입 빈을 생성해서 반환한다.
  • 먼저 Destroy되기 때문에 종료 메서드가 호출되지 않는다.
• 웹 관련 스코프
  • request : 웹 요청이 들어오고 나갈때까지 유지되는 스코프
  • session: 웹 세션이 생성되고 종료될 때 까지 유지되는 스코프
  • application: 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프

프로토타입 스코프 - 싱글톤 빈과 함께 사용 시 문제점

• 스프링 컨테이너에 프로토타입 빈을 요청하면 항상 새로운 객체 인스턴스를 생성해서 반환한다. 하지만 싱글톤 빈과 함께(싱글톤 빈에 주입해서) 사용할 때는 싱글톤 빈이 생성될 때만 의존관계 주입이 일어나기 때문에 해당 싱글톤 빈은 계속해서 같은 프로토타입 빈을 가지고 있게 된다.

해결방법

1. 스프링 애플리케이션 컨텍스트 전체 주입

   단순하게 ApplicationContext(컨테이너) 자체를 싱글톤 빈에 주입해서 로직을 실행할 때마다 getBean을 통해 빈을 불러오고 새로운 프로토타입 빈을 생성해준다.

   • 이렇게 의존관계를 주입받는게 아니라 직접 필요한 의존관계를 찾는 것을 Dependency Lookup (DL) 의존관계 탐색이라고 한다. - 지연 주입?할 때 사용 가능
   • 단점: 스프링 컨테이너에 종속적인 코드가 되고 , 단위 테스트가 어려워 진다.

2. ObjectFactory, ObjectProvider → DL이 필요한 경우 사용

   • 지정한 빈을 컨테이너에서 찾아주는 DL서비스를 제공하는 것이 ObjectProvider
   • ObjectFactory에 기능이 몇 가지 추가된 갓이 ObjectProvider
   • 스프링에 의존하긴 하지만 기능이 단순하기 때문에 단위테스트를 만들거나 mock코드를 만들기 쉽다.

3. Provider

   • 자바 표준, DL 서비스 제공
   • 다른 컨테이너에서 사용 가능

웹 스코프

• 웹 환경에서만 동작한다.

• 스프링이 해당 스코프의 종료시점까지 관리한다. 따라서 종료 메서드가 호출된다.

• request: http 요청 하나가 들어오고 나깔 떄까지 유지되는 스코프, 각각의 http 요청마다 별도의 빈 인스턴스가 생성되고 관리된다.

• session

• application

• websocket

Request 스코프 만들기

• Request 스코프 클래스 코드 (주석 포함)

  @Component
  @Scope("request")
  public class MyLogger {
      private String uuid;
      private String requestURL;
  
      //RequestURL 은 빈이 생성되는 시점에는 알 수 없기 때문에, 외부에서 setter 로 입력받는다.
      public void setRequestURL(String requestURL) {
          this.requestURL = requestURL;
      }
  
      public void log(String message){
          System.out.println("[" + uuid + "]" + "[" + requestURL + "]" + message);
      }
  
      @PostConstruct
      public void init(){
          uuid = UUID.randomUUID().toString(); // 이 빈은 Http 요청 당 하나 씩 생성되므로 UUID를 저장해두면 다른 Http 요청과 구분할 수 있다.
          System.out.println("[" + uuid + "] request scope bean create:" + this);
  
      }
  
      @PreDestroy
      public void close(){
          System.out.println("[" + uuid + "] request scope bean close:" + this);
      }
  }

• Request 스코프를 만들기 위해서는 Https 요청이 들어와야하고 요청이 들어오기 위해서는 컨트롤러와 서비스 클래스를 만들어야 한다.

Request 스코프와 Provider(Provider 사용 시기)

• MyLogger는 Request 스코프이기 때문에 Http 요청이 들어와서 스프링 빈에 올라간다. 그렇기 때문에 처음 스프링을 띄울 때 의존관계 주입이 이루어지지 않는다.
• 이를 해결하기 위해 MyLogger 빈 대신에 MyLogger빈을 찾을 수 있는(DL) ObjectProvider 빈을 주입한다.
• 그리고 Http 요청이 들어오고 난 후 ObjectProvider를 통해 MyLogger를 찾는다.

Request 스코프와 프록시

• Provider를 사용하지 않고 싱글톤을 사용할 때처럼 코드를 간결하게 할 수 있는 방법
• @Scope(value="request" proxyMode= ScopedProxyMode.TARGET_CLASS)

→ 이렇게 하면 MyLogger의 가짜 프록시 클래스를 만들어두고 Http 요청과 상관없이 가짜 프록시 클래스를 미리 주입해 둘 수 있다. 이 가짜 프록시 객체는 요청이 오면 그때 내부에서 진짜 빈을 요청하는 위임 로직이 들어있다.

🔥 Provider를 사용하든, 프록시를 사용하든 중요한 것은 진짜 객체 조회를 꼭 필요한 시점까지 지연처리 한다는 점이다. 이런 특별한 scope는 꼭 필요한 곳에만 최소화해서 사용