Spring Core

영한님의 강의를 요약한 내용입니다.

Spring

Required
- Spring Framework
- Spring Boot
Optional
- Spring Data
- Spring Session
- Spring Security
- Spring Rest Docs
- Spring Batch
- Spring Cloud

좋은 객체지향의 5가지 원칙 (SOLID)

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

하나의 클래스는 하나의 책임만 가져야 한다.
관심사를 분리시켜 변경이 있을 때 파급 효과를 줄일 수 있다.
클라이언트 객체는 실행하는 책임만 담당

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

프로그래머는 “추상화에 의존해야지, 구체화에 의존하면 안된다.”
구현 클래스에 의존하지 말고, 인터페이스에 의존하라.
역할(Interface)에 의존해야 구현의 변경에 유연해질 수 있다.
의존성 주입(DI)은 DIP 원칙을 따름

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

소프트웨어 요소는 확장에서는 열려 있으나 변경에는 닫혀 있어야 한다
애플리케이션을 사용 영역과 구성 영역으로 나눔
인터페이스를 구현한 새로운 클래스에 새로운 기능을 구현하면 사용 역영의 변경을 닫을 수 있다.

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

프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다.

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

특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
인터페이스의 분리로 인터페이스가 명확해지고, 대체 가능성이 높아진다.

스프링과 객체지향

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

프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것

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

의존관계는 정적인 클래스 의존 관계와, 실행 시점에 결정되는 동적인 객체(인스턴스) 의존 관계 둘을 분리해서 생각
스프링이 다형성 + OCP(개방-폐쇄 원칙), DIP(의존관계 역전 원칙) 가능하도록 지원
정적인 클래스 의존관계
- 클래스가 사용하는 import 코드만 보고 의존관계를 쉽게 판단
동적인 객체 인스턴스 의존 관계
- 애플리케이션 실행 시점에 실제 생성된 객체 인스턴스의 참조가 연결된 의존 관계
클라이언트 코드를 변경하지 않고, 클라이언트가 호출하는 대상의 타입 인스턴스 의존관계 변경 가능

DI Container(IoC Container)

객체를 생성하고 관리하면서 의존관계를 연결해 주는 것을 의미
의존관계 주입에 초점을 맞추면 DI 컨테이너라고 불리는게 적합

스프링은 DI, DI Container로 다형성 + OCP, DIP을 적용시켜 클라이언트의 코드 변경 없이 기능 확장이 가능하도록 지원

도메인 설계

도메인 협력, 역할, 책임 관계 (기획자 시점)
- 역할과 구현을 분리하여 자유롭게 구현 객체를 조립할 수 있도로 설계
클래스 다이어그램 (개발자 시점)
객체 다이어그램 (인스턴스끼리의 참조)

Spring Container

/** 
 * AnnotationConfigApplicationContext : ApplicationContext 인터페이스의 구현체
 *  ConfigObject : 구성 정보
 */
ApplicationContext applicationContext = 
  new AnnotationConfigApplicationContext(ConfigObject.class);

ApplicationContext = 스프링 컨테이너
스프링 컨테이너는 XML 기반 또는 애노테이션 기반의 자바 설정 클래스로 만들 수 있음

스프링 컨테이너 생성 과정

스프링 컨테이너 생성
- @Configuration 선언 객체를 설정 정보로 사용
- 또는 new AnnotationConfigApplicationContext(ConfigObject.class)
스프링 빈 등록
- Config 객체에서 @Bean 선언된 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록
- 스프링 빈(스프링 컨테이너에 등록된 객체)은 @Bean 선언된 메서드명을 스프링 빈의 이름으로 사용하거나 @Bean(name="beanName") 처럼 직접 부여도 가능
- 빈 이름은 항상 다른 이름을 사용하자.
  - 같은 이름을 사용하면, 다른 빈이 무시되거나, 덮어쓰이거나 설정에 따라 오류가 발생
스프링 빈 의존관계 설정
- 설정 정보를 참고해서 의존관계 주입(DI)

Bean 조회

AnnotationConfigApplicationContext ac = 
  new AnnotationConfigApplicationContext(AppConfig.class);

@Test
void findAllBean() {
    // 스프링에 등록된 모든 빈 정보 조회
    String[] beanDefinitionNames = ac.getBeanDefinitionNames();
    for (String beanDefinitionName : beanDefinitionNames) {
        // 빈 이름으로 빈 객체(인스턴스) 조회
        Object bean = ac.getBean(beanDefinitionName);
        System.out.println("name=" + beanDefinitionName + " object=" +
        bean);
    }
}

@Test
void findApplicationBean() {
    String[] beanDefinitionNames = ac.getBeanDefinitionNames();
    for (String beanDefinitionName : beanDefinitionNames) {
        BeanDefinition beanDefinition = ac.getBeanDefinition(beanDefinitionName);
        // ROLE_APPLICATION: 직접 등록한 애플리케이션 빈
        // ROLE_INFRASTRUCTURE: 스프링이 내부에서 사용하는 빈
        if (beanDefinition.getRole() == BeanDefinition.ROLE_APPLICATION) {
        Object bean = ac.getBean(beanDefinitionName);
        System.out.println("name=" + beanDefinitionName + " object=" +
        bean);
        }
    }
}

빈 조회 방법

빈 이름과 타입으로 조회: ac.getBean(빈이름, 타입)
해당 타입의 모든 빈 조회: ac.getBeansOfType()
조회 대상 스프링 빈이 없으면 예외 발생
- NoSuchBeanDefinitionException: No bean named 'xxxxx' available

BeanFactory

스프링 컨테이너의 최상위 인터페이스
스프링 빈을 관리하고 조회하는 역할 담당(getBean() 제공)

BeanFactory <- ApplicationContext <- AnnotationConfig, ApplicationContext

ApplicationContext

BeanFactory 기능을 모두 상속받아서 제공
빈을 관리하고 검색하는 기능뿐만 아니라, 수 많은 편리 부가 기능 제공
- MessageSource
  - 메시지소스를 활용한 국제화 기
  - 한국에서 들어오면 한국어, 영어권에서 들어오면 영어 출력
- EnvironmentCapable
  - 환경변수
  - 로컬, 개발, 운영등을 구분해서 처리
- ApplicationEventPublisher
  - 애플리케이션 이벤트
  - 이벤트를 발행하고 구독하는 모델을 편리하게 지원
- ResourceLoader
  - 편리한 리소스 조회
  - 파일, 클래스패스, 외부 등에서 리소스를 편리하게 조회

BeanDefinition

스프링 빈 설정 메타 정보
- @Bean, <bean> 각 하나씩 메타 정보 생성
추상화된 BeanDefinition 덕분에 스프링이 (자바 코드, XML, Groovy 등)다양한 설정 형식을 지원
스프링 컨테이너는 이 메타정보를 기반으로 스프링 빈 생성

Singleton Container

Singleton Pattern

클래스의 인스턴스가 딱 한개만 생성되는 것을 보장하는 디자인 패턴
객체 인스턴스를 두 개 이상 생성하지 못하도록 private 생성자 사용
이미 만들어진 객체를 공유 해서 효율적으로 사용 가능하지만 수 많은 문제점 보유
- 싱글톤 패턴을 구현하기 위해 코드가 길어질 수 있음.
- 의존관계상 클라이언트가 구체 클래스에 의존(DIP를 위반).
- 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높음.
- 테스트의 어려움.
- 내부 속성을 변경하거나 초기화 하기 어려움.
- private 생성자를 사용하다보니 자식 클래스를 만들기 어려움
- 결론적으로 유연성이 떨어지고, 안티패턴으로 불리움.

Singleton Container

스프링 컨테이너: 싱글톤 컨테이너 역할
싱글톤 레지스트: 싱글톤 객체를 생성하고 관리하는 기능

싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤으로 관리
- DIP, OCP, 테스트, private 생성자로 부터 자유로움
싱글톤 객체(스프링 빈)는 상태를 무상태(stateless)로 설계해야 한다.
- 특정 클라이언트에 의존적인 필드가 있으면 안된다.
- 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다.
- 가급적으로 읽기만 가능해야 한다.
- 필드 대신에 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.
스프링 설정 정보는 항상 @Configuration을 사용하여 싱글톤을 보장하자.
- @Configuration 선언 시 바이트코드를 조작하는 CGLIB 기술이 적용되어 싱글톤 보장
- 설정 정보 클래스를 상속받은 xxx@CGLIB 클래스가 싱글톤을 보장

Component Scan

설정 정보 클래스에 @ComponentScan을 명시해 주면, 자동으로 class path를 탐색해서 @Component가 명시된 class들을 스캔해서 스프링 빈으로 등록
- 빈 이름 기본 전략: 앞글자만 소문자로 변경된 클래스명을 사용
- 빈 이름 직접 지정: @Component("beanName")
의존관계 주입은 @Autowired가 해결
- 기본 조회 전략: 타입이 같은 빈을 찾아서 주입

@ComponentScan(
  /**
   * basePackages
   * 탐색할 패키지의 시작 위치(하위 패키지 모두 탐색)
   * 지정하지 않으면 @ComponentScan 선언된 설정 정보 클래스의 패키지가 시작 위치
   * 설정 정보 클래스의 위치를 프로젝트 최상 단에 두는 것을 추천
   * 
   * 스프링 부트는 기본 방법으로 @SpringBootApplication 에 @ComponentScan 포함
   */
    basePackages = {"hello.core", "hello.service"}, 
}

Component Scan 기본 대상
- @Component: 컴포넌트 스캔 탐색 대상
- @Controller : 스프링 MVC 컨트롤러
- @Service : 비즈니스 로직 계층
- @Repository : 스프링 데이터 접근 계층(데이터 계층의 예외를 스프링 예외로 변환)
- @Configuration : 스프링 설정 정보(스프링 빈이 싱글톤을 유지하도록 처리)

Filters

includeFilters : 컴포넌트 스캔 대상 추가 지정
excludeFilters : 컴포넌트 스캔에서 제외할 대상 지정

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

의존관계 자동 주입

생성자 주입 ⭐️

생성자를 통해 의존 관계를 주입받는 방법
딱 1번 호출 보장. 불변-필수 의존관계
불변하게 설계 가능하고, 의존관계 누락 방지(final)
항상 생성자 주입을 선택하자.
lombok 사용 시 @RequiredArgsConstructor

@Component
public class OrderServiceImpl implements OrderService {

  private final MemberRepository memberRepository;
  private final DiscountPolicy discountPolicy;

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

수정자 주입(Setter)

수정자 메서드를 통해서 의존관계를 주입
선택, 변경 가능성이 있는 의존 관계
- 선택적으로 사용할 경우(주입할 대상이 없어도 동작하도록 할 경우)
  - @Autowired(required = false)
- 단, 중간에 의존관계를 변경할 일은 거의 없음

@Component
public class OrderServiceImpl implements OrderService {

  private MemberRepository memberRepository;
  private DiscountPolicy discountPolicy;

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

  @Autowired
  public void setDiscountPolicy(DiscountPolicy discountPolicy) {
    this.discountPolicy = discountPolicy;
  }
}

필드 주입

외부에서 변경이 불가능하여 테스트하기 힘들다는 치명적
가급적 테스트 코드에서만 사용

@Component
public class OrderServiceImpl implements OrderService {

    @Autowired private MemberRepository memberRepository;

    @Autowired private DiscountPolicy discountPolicy;
}

일반 메서드 주입

일반 메서드를 통해 주입
한번에 여러 필드를 주입 받을 수 있는 특징이 있지만 잘 사용하지 않음

@Component
public class OrderServiceImpl implements OrderService {

  private MemberRepository memberRepository;
  private DiscountPolicy discountPolicy;

  @Autowired
  public void init(MemberRepository memberRepository, DiscountPolicy discountPolicy) {

    this.memberRepository = memberRepository;
    this.discountPolicy = discountPolicy;
  }
}

옵션

@Autowired(required=false)

자동 주입할 대상이 없으면 수정자 메서드 자체를 호출하지 않음

@Autowired(required = false)
public void setNoBean1(Member member) {
    System.out.println("setNoBean1 = " + member);
}

org.springframework.lang.@Nullable

자동 주입할 대상이 없으면 null

@Autowired
public void setNoBean2(@Nullable Member member) {
    System.out.println("setNoBean2 = " + member);
}

Optional<>

자동 주입할 대상이 없으면 Optional.empty

@Autowired(required = false)
public void setNoBean3(Optional<Member> member) {
    System.out.println("setNoBean3 = " + member);
}

조회 대상 빈이 2개 이상일 경우

@Autowired

타입 매칭을 시도
여러 빈이 조회되면 필드 이름, 파라미터 이름으로 빈 이름을 추가 매칭

@Autowired
private DiscountPolicy rateDiscountPolicy

@Qualifier

빈 등록 시 @Qualifier 로 추가 구분자 설정
@Qualifier 매칭 ➜ 빈 이름 매칭 ➜ NoSuchBeanDefinitionException 예외

@Component
@Qualifier("mainDiscountPolicy") // 빈 등록 시 이름 설정
public class RateDiscountPolicy implements DiscountPolicy {}

/** 1. 생성자 자동 주입의 경우 **/
@Autowired
public OrderServiceImpl(
        MemberRepository memberRepository,
        @Qualifier("mainDiscountPolicy") DiscountPolicy discountPolicy) {

  this.memberRepository = memberRepository;
  this.discountPolicy = discountPolicy;

}

/** 2. 수정자 자동 주입의 경우 **/
@Autowired
public DiscountPolicy setDiscountPolicy(@Qualifier("mainDiscountPolicy") DiscountPolicy discountPolicy) {
  return discountPolicy;
}

@Primary

@Autowired 시에 여러 빈이 매칭되면 @Primary가 우선권
Database Connection을 가져올 경우 등 은근 사용

@Component
@Primary
public class RateDiscountPolicy implements DiscountPolicy {}

참고. 빈 애노테이션 만들기

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

//

@Component
@MainDiscountPolicy
public class RateDiscountPolicy implements DiscountPolicy {}

//

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

조회한 빈이 모두 필요할 경우

동적으로 Bean을 선택해야할 때, 다형성 코드를 유지하면서 Bean을 사용할 수 있음

public class AllBeanTest {

    @Test
    void findAllBean() {
        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);

        int rateDiscountPrice = discountService.discount(member, 20000, "rateDiscountPolicy");
        assertThat(rateDiscountPrice).isEqualTo(2000);
    }


    static class DiscountService {
        /**
         * Map(Key=스프링 빈 이름, value=DiscountPolicy 타입으로 조회한 모든 스프링 빈)
         * 
         * policyMap
         * {key = "fixDiscountPolicy", value = {FixDiscountPolicy@5731}}
         * {key = "rateDiscountPolicy", value = {RateDiscountPolicy@5732}}
         */
        private final Map<String, DiscountPolicy> policyMap;
        /**
         * DiscountPolicy 타입으로 조회한 모든 스프링 빈을
         *
         * policies
         *  0 = {FixDiscountPolicy@5736} discountFixAmount = 1000
         *  1 = {RateDiscountPolicy@5737} discountPercent = 10
         */
        private final List<DiscountPolicy> policies;

        public DiscountService(Map<String, DiscountPolicy> policyMap,  List<DiscountPolicy> policies) {
            this.policyMap = policyMap;
            this.policies = policies;
        }

        // 원하는 할인 방법은 매개변수로 받은 후, Map에서 꺼내서 사용
        public int discount(Member member, int price, String discountCode) {
            DiscountPolicy discountPolicy = policyMap.get(discountCode);
            return discountPolicy.discount(member, price);
        }
    }
}

편리한 자동 빈 등록 기능을 기본으로 사용하자.
수동 빈 등록은 기술 지원 객체, 다형성을 활용하는(Bean Map, List) 비즈니스 로직에 적용해보자.
직접 등록하는 빈은 설정 정보에 바로 나타나게 하는 것이 유지보수하기 좋다.

빈 생성주기 콜백

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

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

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

생성자는 객체 생성에 책임을, 초기화는 생성된 값들을 활용해서 커넥션 열결과 같은 무거운 동작을 수행
객체를 생성하는 부분과 초기화 하는 부분을 명확하게 나누는 것이 유지보수 관점에서 좋음

스프링의 빈 생명주기 콜백 지원 방법

@PostConstruct, @PreDestory 지원

스프링에서 권장하는 방법
메서드에 애너테이션만 선언하면 되는 편리한 방법
스프링에 종속족이지 않은 기술
외부 라이브러리에 적용 불가(@Bean 설정정보 기능 활용)

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

@Bean(initMethod = "init", destroyMethod = "close")
destroyMethod 기본값이 inferred(추론)으로 등록
- close, shutdown(대부분의 라이브러리가 가지는 종료 메서드 이름) 메서드를 자동으로 호출
메서드 이름의 자유로움
스프링 빈이 스프링 코드에 의존하지 않음
외부 라이브러리에도 적용 가능(코드가 아닌 설정 정보를 사용)

InitializingBean, DisposableBean 인터페이스

InitializingBean.afterPropertiesSet()
DisposableBean.destroy()
지금은 거의 사용하지 않는 방법
- 스프링 전용 인터페이스에 의존
- 초기화, 소멸 메서드 이름 변경 불가
- 외부 라이브러리에 적용 불가

빈 스코프

빈이 존재할 수 있는 범위

스프링은 싱글톤, 프로토타입, 웹 관련 스코프(request, session, application)를 지원

빈 스코프 지정 방법

// 컴포넌트 스캔 자동 등록
@Scope("prototype")
@Component
public class HelloBean {}

...

// 수동 등록
@Scope("prototype")
@Bean
PrototypeBean HelloBean() {
    return new HelloBean();
}

싱글톤

기본 스코프
스프링 컨테이너의 시작~종료까지 유지되는 가장 넓은 범위의 스코프
스프링 컨테이너는 항상 같은 인스턴스의 스프링 빈을 반환

프로토타입

스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입, 초기화까지만 관여하는 매우 짧은 범위의 스코프(종료 메서드 호출 X)
스프링 컨테이너에 조회할 때마다 새로운 인스턴스를 생성해서 반환
- 의존성 주입을 받는 시점에 각각 새로운 프로토타입 빈이 생성
프로토타입 빈을 조회한 클라이언트가 관리. 종료 메서드 호출도 클라이언트가 수행
직접적으로 사용하는 일은 매우 드묾

참고. 싱글톤 빈과 함께 사용시 문제점

스프링은 일반적으로 싱글톤 빈을 사용하여 싱글톤 빈이 프로토타입 빈을 사용
싱글톤 빈은 생성 시점에만 의존성 주입을 받으므로, 프로토타입 빈을 사용할 때마다 새로 생성해서 사용하고자하는 의도와 다르게 프로토타입 빈 스코프가 싱글톤 빈과 함께 계속 유지
ObjectProvider 을 활용한 문제 해결
- 지정한 빈을 컨테이너에서 대신 찾아주는 DL(Dependency Lookup) 서비스 제공

@Autowired
private ObjectProvider<PrototypeBean> prototypeBeanProvider;

public int logic() {
    PrototypeBean prototypeBean = prototypeBeanProvider.getObject();
    prototypeBean.addCount();
    int count = prototypeBean.getCount();
    return count;
}

웹 스코프

웹 환경에서만 동작
프로토타입 빈과 다르게 스프링이 해당 스코프의 종료시점까지 관리
유지보수를 위해 필요한 곳에만 최소화해서 사용 권장

request:

HTTP 요청 하나가 들어오고 나갈 때까지 유지되는 스코프
각각의 HTTP 요청마다 별도의 빈 인스턴스 생성/관리

/**
 * @Scope
 * - 실제 고객 요청이 들어와야 request 스코프 객체의 빈이 생성되므로 빈 생성 지연이 필요.
 * - 적용 대상에 따라 ScopedProxyMode.TARGET_CLASS, ScopedProxyMode.INTERFACES 선택
 * 
 * - HTTP request와 관계 없이 싱글톤처럼 동작하는 프록시 객체를 다른 빈에 미리 의존성 주입
 * - 요청이 오면 프록시 객체 내부에서 원본 객체을 요청하는 위임 로직
 */
@Component
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class MyLogger {...}

session:

HTTP Session과 동일한 생명주기(생성~종료)를 가지는 스코프

application:

서블릿 컨텍스트(ServletContext)와 동일한 생명주기를 가지는 스코프

websocket:

웹 소켓과 동일한 생명주기를 가지는 스코프

Last updated 1 year ago