ZeroOne

빈 스코프란?

빈이 존재할 수 있는 범위(기간)를 뜻한다.

1. 프로토타입 스코프의 빈을 스프링 컨테이너에 요청한다.
2. 스프링 컨테이너는 이 시점에 프로토타입 빈을 생성하고, 필요한 의존관계를 주입한다.

3. 스프링 컨테이너는 생성한 프로토타입 빈을 클라이언트에 반환한다.
4. 이후에 스프링 컨테이너에 같은 요청이 오면 항상 새로운 프로토타입 빈을 생성해서 반환한다.

*프로토타입 빈의 경우, 스프링 컨테이너에서 관리 안하므로 preDestroy같은 이벤트 발생안함!

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

clientBean 은 싱글톤이므로, 보통 스프링 컨테이너 생성 시점에 함께 생성되고, 의존관계 주입도 발생한다.
1. clientBean 은 의존관계 자동 주입을 사용한다. 주입 시점에 스프링 컨테이너에 프로토타입 빈을 요청한다.

2. 스프링 컨테이너는 프로토타입 빈을 생성해서 clientBean 에 반환한다. 프로토타입 빈의 count 필드 값은 0이다.
이제 clientBean 은 프로토타입 빈을 내부 필드에 보관한다. (정확히는 참조값을 보관한다.)

클라이언트 A는 clientBean 을 스프링 컨테이너에 요청해서 받는다.싱글톤이므로 항상 같은 clientBean 이 반환된다.
3. 클라이언트 A는 clientBean.logic() 을 호출한다.
4. clientBean 은 prototypeBean의 addCount() 를 호출해서 프로토타입 빈의 count를 증가한다. count값이 1이 된다.

클라이언트 B는 clientBean 을 스프링 컨테이너에 요청해서 받는다.싱글톤이므로 항상 같은 clientBean 이 반환된다.
여기서 중요한 점이 있는데, clientBean이 내부에 가지고 있는 프로토타입 빈은 이미 과거에 주입이 끝난 빈이다. 주입 시점에 스프링 컨테이너에 요청해서 프로토타입 빈이 새로 생성이 된 것이지, 사용 할 때마다 새로 생성되는 것이 아니다!
5. 클라이언트 B는 clientBean.logic() 을 호출한다.
6. clientBean 은 prototypeBean의 addCount() 를 호출해서 프로토타입 빈의 count를 증가한다. 원래 count 값이 1이었으므로 2가 된다.

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

웹 스코프

웹 스코프의 특징

• 웹 스코프는 웹 환경에서만 동작한다.
• 웹 스코프는 프로토타입과 다르게 스프링이 해당 스코프의 종료시점까지 관리한다. 따라서 종료 메서드가 호출된다.

웹 환경 추가 - build.gradle

//web 라이브러리 추가
implementation 'org.springframework.boot:spring-boot-starter-web'

spring-boot-starter-web 라이브러리를 추가하면 스프링 부트는 내장 톰켓 서버를 활용해서 웹 서버와 스프링을 함께 실행시킨다.

스프링 애플리케이션을 실행하는 시점에 싱글톤 빈은 생성해서 주입이 가능하지만, request 스코프 빈은 아직 생성되지 않는다. 이 빈은 실제 고객의 요청이 와야 생성할 수 있다!

proxyMode = ScopedProxyMode.TARGET_CLASS 를 추가.

• 적용 대상이 인터페이스가 아닌 클래스면 TARGET_CLASS 를 선택
• 적용 대상이 인터페이스면 INTERFACES 를 선택

이렇게 하면 MyLogger의 가짜 프록시 클래스를 만들어두고 HTTP request와 상관 없이 가짜 프록시 클래스를 다른 빈에 미리 주입해 둘 수 있다.

CGLIB라는 라이브러리로 내 클래스를 상속 받은 가짜 프록시 객체를 만들어서 주입한다.

스프링 빈의 이벤트 라이프사이클

스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존관계 주입 -> 초기화 콜백 -> 사용 -> 소멸전 콜백 -> 스프링 종료

스프링은 크게 3가지 방법으로 빈 생명주기 콜백을 지원한다.

• 인터페이스(InitializingBean, DisposableBean)

package hello.core.lifecycle;

import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;

public class NetworkClient implements InitializingBean, DisposableBean {
    private String url;

	public NetworkClient() { System.out.println("생성자 호출, url = " + url); }
    
    public void setUrl(String url) { this.url = url; }

	//서비스 시작시 호출
    public void connect() {
        System.out.println("connect: " + url);
    }
    
    public void call(String message) {
        System.out.println("call: " + url + " message = " + message);
    }
    
	//서비스 종료시 호출
    public void disConnect() {
        System.out.println("close + " + url);
    }
    
    @Override
    public void afterPropertiesSet() throws Exception {
    	connect();
        call("초기화 연결 메시지");
    }
    
    @Override
    public void destroy() throws Exception {
    	disConnect();
    }
}

• 설정 정보에 초기화 메서드, 종료 메서드 지정

package hello.core.lifecycle;

public class NetworkClient {

    private String url;

    public NetworkClient() {
        System.out.println("생정자 호출, url = " + url);
    }

    public void setUrl(String url) {
        this.url = url;
    }

    // 서비스 시작시 호출
    public void connect() {
        System.out.println("connect: " + url);
    }

    public void call(String message) {
        System.out.println("call: " + url + " message = " + message);
    }

    // 서비스 종료시 호출
    public void disconnect() {
        System.out.println("close: " + url);
    }

    public void init() {
        System.out.println("NetworkClient.init");
        connect();
        call("초기화 연결 메시지");
    }

    public void close() throws Exception {
        System.out.println("NetworkClient.close");
        disconnect();
    }
}

@Configuration
static class LifeCycleConfig {
    @Bean(initMethod = "init", destroyMethod = "close")
    public NetworkClient networkClient() {
        NetworkClient networkClient = new NetworkClient();
        networkClient.setUrl("http://hello-spring.dev");
        return networkClient;
    }
}

• @PostConstruct, @PreDestroy 애노테이션 지원(권장)

package lifecycle;

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;

public class NetworkClient {

    private String url;

    public NetworkClient() {
        System.out.println("생정자 호출, url = " + url);
    }

    public void setUrl(String url) {
        this.url = url;
    }

    // 서비스 시작시 호출
    public void connect() {
        System.out.println("connect: " + url);
    }

    public void call(String message) {
        System.out.println("call: " + url + " message = " + message);
    }

    // 서비스 종료시 호출
    public void disconnect() {
        System.out.println("close: " + url);
    }

    @PostConstruct
    public void init() {
        System.out.println("NetworkClient.init");
        connect();
        call("초기화 연결 메시지");
    }

    @PreDestroy
    public void close() throws Exception {
        System.out.println("NetworkClient.close");
        disconnect();
    }
}

참고: @Autowired 의 기본 동작은 주입할 대상이 없으면 오류가 발생한다. 주입할 대상이 없어도 동작하게 하려면 @Autowired(required = false) 로 지정하면 된다.

• 생성자 호출시점에 딱 1번만 호출되는 것이 보장된다.
• 불변, 필수 의존관계에 사용
• 중요! 생성자가 딱 1개만 있으면 @Autowired를 생략해도 자동 주입 된다. 물론 스프링 빈에만 해당한다.

불변

대부분의 의존관계 주입은 한번 일어나면 애플리케이션 종료시점까지 의존관계를 변경할 일이 없다. 오히려 대부분의 의존관계는 애플리케이션 종료 전까지 변하면 안된다.(불변해야 한다.)
수정자 주입을 사용하면, setXxx 메서드를 public으로 열어두어야 한다.
누군가 실수로 변경할 수 도 있고, 변경하면 안되는 메서드를 열어두는 것은 좋은 설계 방법이 아니다. 생성자 주입은 객체를 생성할 때 딱 1번만 호출되므로 이후에 호출되는 일이 없다. 따라서 불변하게 설계할 수 있다.

조회 빈이 2개 이상 - 문제

1. @Autowired 필드 명 매칭 (필드 명을 빈 이름으로 변경)

@Autowired 매칭 정리
      1) 타입 매칭
      2) 타입 매칭의 결과가 2개 이상일 때 필드 명, 파라미터 명으로 빈 이름 매칭

2. @Qualifier 사용
@Qualifier 는 추가 구분자를 붙여주는 방법이다. 주입시 추가적인 방법을 제공하는 것이지 빈 이름을 변경하는 것은 아니다

<빈 등록시 @Qualifier 붙임>

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

@Qualifier("mainDiscountPolicy") 이렇게 문자를 적으면 컴파일시 타입 체크가 안된다. 다음과 같은 애노테이션을 만들어서 문제를 해결할 수 있다.

package hello.core.annotataion;
import org.springframework.beans.factory.annotation.Qualifier;
import java.lang.annotation.*;
@Target({ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER,
ElementType.TYPE, ElementType.ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Qualifier("mainDiscountPolicy")
public @interface MainDiscountPolicy {
}

애노테이션에는 상속이라는 개념이 없다.
이렇게 여러 애노테이션을 모아서 사용하는 기능은 스프링이 지원해주는 기능이다.-->???
@Qulifier 뿐만 아니라 다른 애노테이션들도 함께 조합해서 사용할 수 있다. 단적으로 @Autowired도 재정의 할 수 있다. 물론 스프링이 제공하는 기능을 뚜렷한 목적 없이 무분별하게 재정의 하는 것은 유지보수에 더 혼란만 가중할 수 있다.

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

public class AllBeanTest {
    @Test
    void findAllBean() {
    	// 컴포넌트 스캔(AutoAppConfig)으로 등록한 빈들을 DiscountService에 저장
          ApplicationContext ac = new AnnotationConfigApplicationContext(AutoAppConfig.class, DiscountService.class);
          DiscountService discountService = ac.getBean(DiscountService.class);
          Member member = new Member(1L, "userA", Grade.VIP);
          int discountPrice = discountService.discount(member, 10000, "fixDiscountPolicy");
          assertThat(discountService).isInstanceOf(DiscountService.class);
          assertThat(discountPrice).isEqualTo(1000);
    }
    static class DiscountService {
    	private final Map<String, DiscountPolicy> policyMap;
        private final List<DiscountPolicy> policies;
        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);
            System.out.println("discountCode = " + discountCode);
            System.out.println("discountPolicy = " + discountPolicy);
            return discountPolicy.discount(member, price);
        }
    }
}

주입 분석

• Map<String, DiscountPolicy> : map의 키에 스프링 빈의 이름을 넣어주고, 그 값으로 DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아준다.
• List<DiscountPolicy> : DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아준다.
• 만약 해당하는 타입의 스프링 빈이 없으면, 빈 컬렉션이나 Map을 주입한다.

자동, 수동의 올바른 실무 운영 기준

스프링은 자바코드의 @Bean이나 XML의 <bean> 같은 설정 정보가 없어도 자동으로 스프링 빈을 등록하는 @ComponentScan이라는 기능을 제공한다.

또, 의존관계도 자동으로 주입하는 @Autowired라는 기능도 제공한다.

package hello.core;
    
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.FilterType;
import static org.springframework.context.annotation.ComponentScan.*;

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

}

@Autowired 는 의존관계를 자동으로 주입해준다

2. @Autowired 의존관계 자동 주입

• 생성자에 파라미터가 많아도 다 찾아서 자동으로 주입한다.

탐색 위치와 기본 스캔 대상

 @ComponentScan(
    includeFilters = @Filter(type = FilterType.ANNOTATION, classes = MyIncludeComponent.class),
    excludeFilters = @Filter(type = FilterType.ANNOTATION, classes = MyExcludeComponent.class)
  )

싱글톤 방식의 주의점

싱글톤 패턴이든, 스프링 같은 싱글톤 컨테이너를 사용하든, 객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안된다. 즉, 무상태(stateless)로 설계해야 한다!

• 특정 클라이언트에 의존적인 필드가 있으면 안된다.
• 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다!
• 가급적 읽기만 가능해야 한다.
• 필드 대신에 자바에서 공유되지 않는, 지역변수, 파라미터 ThreadLocal 등을 사용해야 한다.

스프링 빈의 필드에 공유 값을 설정하면 정말 큰 장애가 발생할 수 있다!!

그럼에도 불가피하게 사용해야 될 경우는? 옵션을 제공한다.

@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();
      }
... }

memberService 빈을 만드는 코드를 보면 memberRepository() 를 호출한다. 이 메서드를 호출하면 new MemoryMemberRepository() 를 호출한다. orderService 빈을 만드는 코드도 동일하게 memberRepository() 를 호출한다. 이 메서드를 호출하면 new MemoryMemberRepository() 를 호출한다.

순수한 클래스라면 다음과 같이 출력되어야 한다.

 // class hello.core.AppConfig

그런데 예상과는 다르게 클래스 명에 xxxCGLIB가 붙으면서 상당히 복잡해진 것을 볼 수 있다. 이것은 내가 만든 클래스가 아니라 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들고, 그 다른 클래스를 스프링 빈으로 등록한 것이다!

스프링 컨테이너는 설정 정보를 참고해서 의존관계를 주입(DI)한다.

싱글톤 방식

스프링 빈 조회 - 기본

     NoSuchBeanDefinitionException: No bean named 'xxxxx' available

스프링 빈 조회 - 동일한 타입이 둘 이상

• 타입으로 조회시 같은 타입의 스프링 빈이 둘 이상이면 오류가 발생한다. 이때는 빈 이름을 지정하자.
• ac.getBeansOfType() 을 사용하면 해당 타입의 모든 빈을 조회할 수 있다.

BeanFactory

• 스프링 컨테이너의 최상위 인터페이스다.
• 스프링 빈을 관리하고 조회하는 역할을 담당한다.
• getBean() 을 제공한다.
• 지금까지 우리가 사용했던 대부분의 기능은 BeanFactory가 제공하는 기능이다

ApplicatonContext가 제공하는 부가기능

• 메시지소스를 활용한 국제화 기능
  예를 들어서 한국에서 들어오면 한국어로, 영어권에서 들어오면 영어로 출력
• 환경변수
  로컬, 개발, 운영등을 구분해서 처리
• 애플리케이션 이벤트
  이벤트를 발행하고 구독하는 모델을 편리하게 지원
• 편리한 리소스 조회
  파일, 클래스패스, 외부 등에서 리소스를 편리하게 조회

정리

• ApplicationContext는 BeanFactory의 기능을 상속받는다.
• ApplicationContext는 빈 관리기능 + 편리한 부가 기능을 제공한다.
• BeanFactory를 직접 사용할 일은 거의 없다. 부가기능이 포함된 ApplicationContext를 사용한다.
• BeanFactory나 ApplicationContext를 스프링 컨테이너라 한다.

스프링은 어떻게 이런 다양한 설정 형식을 지원하는 것일까? 그 중심에는 BeanDefinition 이라는 추상화가 있다.

쉽게 이야기해서 역할과 구현을 개념적으로 나눈 것이다!

• XML을 읽어서 BeanDefinition을 만들면 된다.
• 자바 코드를 읽어서 BeanDefinition을 만들면 된다.
• 스프링 컨테이너는 자바 코드인지, XML인지 몰라도 된다. 오직 BeanDefinition만 알면 된다.

BeanDefinition 을 빈 설정 메타정보라 한다.

• @Bean , <bean> 당 각각 하나씩 메타 정보가 생성된다.

스프링 컨테이너는 이 메타정보를 기반으로 스프링 빈을 생성한다.

new MemoryMemberRepository() 이 부분이 중복 제거되었다. 이제 MemoryMemberRepository 를 다른 구현체로 변경할 때 한 부분만 변경하면 된다.
AppConfig 를 보면 역할과 구현 클래스가 한눈에 들어온다. 애플리케이션 전체 구성이 어떻게 되어있는지 빠르게 파악할 수 있다

의존관계 주입 DI(Dependency Injection)

스프링 컨테이너

• 객체 지향 프로그래밍은 컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러 개의 독립된 단위, 즉 "객체"들의 모임으로 파악하고자 하는 것이다. 각각의 객체는 메시지 를 주고받고, 데이터를 처리할 수 있다. (협력)
• 객체 지향 프로그래밍은 프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용된다.

• SRP: 단일 책임 원칙(single responsibility principle)

         - 한 클래스는 하나의 책임만 가져야 한다.

         - 변경이 있을 때 파급효과가 적어야 한다.

• OCP: 개방-폐쇄 원칙 (Open/closed principle)

         - 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.

         - 다음과 같이 다형성을 활용해 역할과 구현을 분리해도 서버단의 구현객체를 변경하려면 클라이언트 코드를 변경해야 한다.

MemberRepository m = new MemoryMemberRepository(); //기존 코드
MemberRepository m = new JdbcMemberRepository(); //변경 코드

• LSP: 리스코프 치환 원칙 (Liskov substitution principle)

    - 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
    - 부모 클래스의 행동규약을 자식 클래스가 위반하지 말아야 한다.
  

  ex) 오버라이딩 잘 못 하는 경우 :

    1. 자식 클래스가 부모 클래스의 변수의 타입을 바꾸거나 메소드의 파라미터 또는 리턴값의 타입 or 갯수를 바꾸는 경우
    2. 자식 클래스가 부모 클래스의 의도와 다르게 메소드를 오버라이딩 하는 경우

   

• ISP: 인터페이스 분리 원칙 (Interface segregation principle)

          - 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.

             즉, 역할을 여러 개로 구별하여 쪼개자.

• DIP: 의존관계 역전 원칙 (Dependency inversion principle)