[스프링 핵심 원리 - 기본편] (2) 스프링 핵심 원리 이해

전체 내용 정리보단 나중에 다시 찾아 볼만한 내용들만 정리해보려고 한다.

 

---

1. 예제 만들기

프로젝트 생성

스프링 부트 3.0 이상 선택

• JDK 17 이상 사용
• javax 패키지 -> jakarta 패키지 (옛날 자료를 찾아보다 보면 javax로 되어있는 경우가  많음)

 

스프링 부트 3.2부터 [file > settings]에서 gradle 검색 후 [Build and run using]과 [Run tests using]에 Gradle 옵션 사용

• 기본값이므로 수정할 필요 없음

 

---

로직 테스트

예시

package hello.core.member;

import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;

class MemberServiceTest {

     MemberService memberService = new MemberServiceImpl();
 
     @Test
     @DisplayName("회원가입 테스트")
     void join() {
 
         //given
         Member member = new Member(1L, "memberA", Grade.VIP);

         //when
         memberService.join(member);
         Member findMember = memberService.findMember(1L);

         //then
         Assertions.assertThat(member).isEqualTo(findMember);
     }
}

• 로직 테스트를 하고 싶은 class에서 [ctrl + shift + t]를 누르면 테스트를 생성할 수 있음

• test용 메서드에 @Test 붙이기
  • @DisplayName으로 테스트에 이름을 붙일 수 있음
• 내부는 given-when-then 형식으로 작성하는 걸 추천함
  • given: 변수 생성
  • when: 로직 실행
  • then: 로직 결과 테스트
• Assertions.assertThat("테스트할 객체").isEqualTo("로직 결과");
  • junit 패키지에서 제공하는 테스트용 메서드
  • ex. isNotEqualTo(), isIn(), isInstanceOf()

 

---

2. 객체 지향 원리 적용하기

관심사의 분리

AppConfig를 생성해 구현 객체를 생성하고 연결하는 역할을 하게 함 (프로그램 제어 흐름에 대한 권한을 갖게 됨)

• FixDiscountPolicy를 RateDiscountPolicy로 변경하더라도 구성 영역만 변경하면 되고 사용 영역은 변경할 필요 없음
• SOLID 중 SRP, OCP, DIP 만족

 

---

제어의 역전 IoC(Inversion of Control)

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

• 프레임워크가 내가 작성한 코드를 제어하고, 대신 실행한다면? -> 프레임워크
• 내가 작성한 코드가 직접 제어의 흐름을 담당한다면? -> 라이브러리

 

---

의존 관계 주입 DI(Dependency Injection)

a. 정적인 class 의존 관계

class가 사용하는 import 코드만 보고 의존 관계를 쉽게 판단 가능 (애플리케이션을 실행하지 않아도 가능함)

• 단, class 의존 관계만으론 실제 어떤 객체가 주입되는지는 알 수 없음

 

b. 동적인 객체 인스턴스 의존 관계

애플리케이션 실행 시점(런타임)에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해 클라이언트와 서버의 실제 의존관계가 연결되는 것

• 객체 인스턴스를 생성하고, 그 참조값을 전달해 연결됨
• 클라이언트 코드를 변경하지 않고, 클라이언트가 호출하는 대상의 타입 인스턴스를 변경할 수 있음
• DI를 사용하면 정적인 class 의존 관계를 변경하지 않고, 동적인 객체 인스턴스 의존 관계를 쉽게 변경할 수 있음

 

---

IoC 컨테이너, DI 컨테이너

AppConfig처럼 객체를 생성하고 관리하면서, 의존 관계를 연결해 주는 것

• DI에 초점을 맞춰 최근에는 주로 DI 컨테이너라고 부름
• (+ 어샘블러, 오브젝트 팩토리 등)

 

---

스프링으로 전환하기

a. AppConfig를 스프링 기반으로 변경

package hello.core;

import ...

@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();
     }
     @Bean
     public DiscountPolicy discountPolicy() {
     	return new RateDiscountPolicy();
     }
}

• AppConfig에 설정을 구성한다는 뜻의 @Configuration 붙이기
• 각 메서드에 @Bean 붙이기
  • 스프링 컨테이너(ApplicationContext)에 스프링 빈으로 등록됨

 

b. 스프링 컨테이너

ApplicationContext를 스프링 컨테이너라고 함

• 스프링 컨테이너는 @Configuration이 붙은 AppConfig를 설정(구성) 정보로 사용함
• @Bean이라 적힌 메서드를 모두 호출해 반환된 객체를 스프링 컨테이너에 등록함
• 스프링 빈 = 스프링 컨테이너에 등록된 객체
  • @Bean이 붙은 메서드의 명을 스프링 빈의 이름으로 사용함 ex. memberService, orderService