no image
[Spring 핵심원리 - 기본] 스프링 컨테이너와 스프링 빈
이 글은 인프런 김영한님의 Spring 강의를 바탕으로 개인적인 정리를 위해 작성한 글입니다. 스프링 컨테이너 생성 ApplicationContext 를 스프링 컨테이너라 한다. ApplicationContext 는 인터페이스이다. 스프링 컨테이너는 XML을 기반으로 만들 수 있고, 애노테이션 기반의 자바 설정 클래스로 만들 수 있다. 이전에 AppConfig 를 사용했던 방식이 어노테이션 기반의 자바 설정 클래스로 스프링 컨테이너를 만든 것이다. 자바 설정 클래스를 기반으로 스프링 컨테이너( ApplicationContext )를 만들어보자. //스프링 컨테이너 생성 ApplicationContext applicationContext = new AnnotationConfigApplicationConte..
2024.01.29
no image
[Spring 핵심원리 - 기본] 객체 지향 원리 적용
이 글은 인프런 김영한님의 Spring 강의를 바탕으로 개인적인 정리를 위해 작성한 글입니다. 새로운 할인 정책 개발 새로운 할인 정책을 확장해보자. 악덕 기획자가 서비스 오픈 직전에 할인 정책을 변경하고 싶어한다. 기존에는 VIP 고객이 주문 금액에 관계없이 일정 금액(예: 1000원)을 할인받는 방식이었지만, 이제 주문 금액의 일정 비율(예: 10%)을 할인하는 방식으로 변경하고자 한다. 순진 개발자는 처음부터 고정 금액 할인 방식에 반대했지만, 악덕 기획자는 애자일 개발 방식을 인용하며 변화에 대응할 것을 주장한다. 순진 개발자는 유연한 설계를 위해 객체지향 설계 원칙을 이미 준수했기 때문에 상관없다고 생각한다. 순진 개발자가 정말 객체지향 설계 원칙을 잘 준수 했는지 확인해보자. 이번에는 주문한 ..
2024.01.28
no image
[Spring 핵심 원리 - 기본] 예제 만들기
이 글은 인프런 김영한님의 Spring 강의를 바탕으로 개인적인 정리를 위해 작성한 글입니다. 회원 도메인 설계 회원 도메인 요구사항 회원을 가입하고 조회할 수 있다. 회원은 일반과 VIP 두 가지 등급이 있다. 회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다. (미확정) 회원 도메인 협력 관계 회원 클래스 다이어그램 회원 객체 다이어그램 회원 서비스: MemberServiceImpl 구현 클래스가 하나밖에 없을 때는 Impl을 관례적으로 붙인다고 한다. 회원 도메인 개발 회원 엔티티 회원 등급 package hello.core.member; public enum Grade { BASIC, VIP } 회원 엔티티 package hello.core.member; public cl..
2024.01.27
no image
[Spring 핵심원리 - 기본] 객체 지향 설계와 스프링
이 글은 인프런 김영한님의 Spring 강의를 바탕으로 개인적인 정리를 위해 작성한 글입니다. 자바 진영의 표준 기술이었던 Enterprise Java Beans (EJB)는 복잡하고 어려우며 의존적이고 느렸음. 스프링 2002년 로드 존슨 책 출간 EJB의 문제점 지적 지금의 스프링 핵심 개념과 기반 코드가 들어있음 BeanFactory, ApplicationContext, POJO, 제어 역전, 의존관계 주입 단순함의 승리 현재 사실상 표준 기술 EJB 엔티티빈 기술을 대체 -> 하이버네이트 -> JPA JPA는 인터페이스이다. 따라서 구현체가 필요한데, 대표적인 구현체는 하이버네이트, EclipseLink 등이 있다. 스프링 생태계 스프링은 여러 가지 기술들의 모음. 스프링 프레임워크: 스프링의 핵..
2024.01.26
no image
[Spring 입문] AOP (Aspect Oriented Programming)
이 글은 인프런 김영한님의 Spring 강의를 바탕으로 개인적인 정리를 위해 작성한 글입니다. AOP가 필요한 상황 몇개의 메서드에 실행시간을 체크해보고싶은 상황이라고 한다면 해당 메서드들의 시작과 끝에 시간을 측정하고 출력하는 코드를 붙여야할 것이다. 다행히 그게 몇개 밖에 되지않는다면 괜찮겠지만 만약 몇십개, 몇백개라면 노가다 작업을 해야할 것이다. 예를 들어, AOP를 적용하지 않고, 각 메서드마다 실행시간을 측정을 해야한다면 아래와 같은 문제점을 만나게 된다. 회원가입, 회원 조회에 시간을 측정하는 기능은 핵심 관심 사항이 아니다. 시간을 측정하는 로직은 공통 관심 사항이다. 시간을 측정하는 로직과 핵심 비즈니스의 로직이 섞여서 유지보수가 어렵다. 시간을 측정하는 로직을 별도의 공통 로직으로 만들..
2024.01.25
no image
[IntelliJ] 자주 사용하는 단축키 정리
Maccommand + shift + t : 테스트 케이스 생성option + enter : static importcommand + option + v : 리턴 값을 받아줄 변수 자동 생성command + n : 생성자, getter, setter 등 자동 생성command + d : 라인 복제ctrl + t : 리팩토링option + command + m : 메서드 추출 리팩토링 (extract method)command + shift + 왼쪽 or 오른쪽 : 프로젝트 탐색창 좌우 크기조절command + option + b + 클릭: 인터페이스의 구현체 리스트를 보여줌command + p : 생성자 목록command + e : 최근 실행 파일shift + shift : 전체 검색command + d..
2024.01.24
no image
[Spring 입문] 스프링 DB 접근 기술
이 글은 인프런 김영한님의 Spring 강의를 바탕으로 개인적인 정리를 위해 작성한 글입니다. H2 데이터베이스 설치 H2 데이터베이스는 개발이나 테스트 용도로 가볍고 편리한 DB, 웹 화면 제공한다. https://www.h2database.com/html/main.html 위 사이트에서 H2 데이터베이스를 설치한다. 브라우저 창이 열리면서 다음과같은 화면이 출력된다. JDBC URL : jdbc:h2:~/test (최초 한번 입력)를 입력한다. ~/test는 home에 있는 test파일을 의미한다. window에서 home은 사용자 폴더가 된다. 사용자명과 비밀번호는 건드리지 않고 [연결] 버튼을 누른다. 그러면 해당 폴더에 위와 같은 파일이 생성된다. 아래와같이 H2 Database에 연결이되며, ..
2024.01.24
no image
[Java] static import
static import는 클래스의 정적 멤버(메서드와 필드)를 클래스 이름 없이 직접 사용할 수 있도록 해준다. 이를 통해 코드의 가독성을 높일 수 있지만, 과도하게 사용할 경우 어느 클래스에서 메서드나 필드가 정의되었는지 혼란을 줄 수 있다. 예를들어, static import를 사용하지 않는 경우, 예를 들어 Math 클래스의 sqrt 메서드를 사용하려면 클래스 이름을 명시해야 한다. double result = Math.sqrt(25); // Math 클래스의 sqrt 메서드 사용 static import를 사용하면, 메서드를 클래스 이름 없이 직접 호출할 수 있다 import static java.lang.Math.sqrt; ... double result = sqrt(25); // Math.s..
2024.01.23

이 글은 인프런 김영한님의 Spring 강의를 바탕으로 개인적인 정리를 위해 작성한 글입니다.


스프링 컨테이너 생성

  • ApplicationContext 를 스프링 컨테이너라 한다.
  • ApplicationContext 는 인터페이스이다.
  • 스프링 컨테이너는 XML을 기반으로 만들 수 있고, 애노테이션 기반의 자바 설정 클래스로 만들 수 있다.
  • 이전에 AppConfig 를 사용했던 방식이 어노테이션 기반의 자바 설정 클래스로 스프링 컨테이너를 만든 것이다.

 

자바 설정 클래스를 기반으로 스프링 컨테이너( ApplicationContext )를 만들어보자.

//스프링 컨테이너 생성
ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
  • new AnnotationConfigApplicationContext(AppConfig.class);
    이 클래스는 ApplicationContext 인터페이스의 구현체이다. 즉, Appconfig를 구현 클래스로 설정한 것이다.
더 정확히는 스프링 컨테이너를 부를 때 BeanFactory , ApplicationContext 로 구분해서 이야기 한다.
BeanFactory가 최상위 인터페이스이고 ApplicationContext이 바로 하위 인터페이스이다.
BeanFactory 를 직접 사용하는 경우는 거의 없으므로 일반적으로 ApplicationContext 를 스프링 컨테이너라 한다.

 

스프링 컨테이너의 생성 과정

 

1. 스프링 컨테이너 생성

new AnnotationConfigApplicationContext(AppConfig.class)
  • 스프링 컨테이너를 생성할 때는 구성 정보를 지정해주어야 한다.
  • 여기서는 AppConfig.class 를 구성 정보로 지정했다.

 

2. 스프링 빈 등록

  • 스프링 컨테이너는 파라미터로 넘어온 설정 클래스 정보를 사용해서 스프링 빈을 등록한다.
Bean 이름
빈 이름은 메서드 이름을 사용한다.
빈 이름을 직접 부여할 수 도 있다. -> @Bean(name="memberService2")
주의
빈 이름은 항상 다른 이름을 부여해야 한다.
같은 이름을 부여하면, 다른 빈이 무시되거나, 기존 빈을 덮어버 리거나 설정에 따라 오류가 발생한다.

 

3. 스프링 빈 의존관계 설정 - 준비

 

4. 스프링 빈 의존관계 설정 - 완료

  • 스프링 컨테이너는 설정 정보를 참고해서 의존관계를 주입(DI)한다.
  • 단순히 자바 코드를 호출하는 것 같지만, 차이가 있다. 

 

참고
스프링은 빈을 생성하고, 의존관계를 주입하는 단계가 나누어져 있다.
그런데 이렇게 자바 코드로 스프링 빈을 등록하면 생성자를 호출하면서 의존관계 주입도 한번에 처리된다.
여기서는 이해를 돕기 위해 개념적으로 나누어 설명한 것이다.

 

컨테이너에 등록된 빈(bean) 조회

모든 빈 출력하기

  • 실행하면 스프링에 등록된 모든 빈 정보를 출력할 수 있다.
  • ac.getBeanDefinitionNames() : 스프링에 등록된 모든 빈 이름을 조회한다.
  • ac.getBean() : 빈 이름으로 빈 객체(인스턴스)를 조회한다.
public class ApplicationContextInfoTest {

    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    @Test
    @DisplayName("모든 빈 출력하기")
    void findAllBean(){
        String[] beanDefinitionNames = ac.getBeanDefinitionNames();
        for (String beanDefinitionName : beanDefinitionNames) {
            Object bean = ac.getBean(beanDefinitionName);
            System.out.println("name = " + beanDefinitionName + " object = " + bean);
        }
    }
}

 

spring이 사용하는 빈과 직접 등록한 빈이 모두 출력되었다.

 

AnnotationConfigApplicationContext.getbean()

getBean()메소드는 이 컨텍스트 안에서 관리되고 있는 빈(bean)을 검색하고 반환하는 데 사용된다.
빈은 Spring에서 관리하는 객체로, 의존성 주입을 통해 다른 빈이나 기능에 접근하고, Spring 프레임워크의 생명주기 관리를 받는다.


빈 이름으로 검색
public Object getBean(String name) throws BeansException​

name: 검색하고자 하는 빈의 이름이다.
이 이름은
@Bean 어노테이션을 사용하거나 XML 설정 파일에서 정의된다.

빈 타입으로 검색

public <T> T getBean(Class<T> requiredType) throws BeansException

requiredType: 검색하고자 하는 빈의 타입이다.
이 메소드는 지정된 타입과 호환되는 빈을 반환한다.


빈 이름과 타입으로 검색
public <T> T getBean(String name, Class<T> requiredType) throws BeansException​

name: 검색하고자 하는 빈의 이름이다.
requiredType: 검색하고자 하는 빈의 타입이다.
이 메소드는 지정된 이름과 타입 모두에 해당하는 빈을 반환한다.

 

애플리케이션 빈 출력하기

  • 스프링이 내부에서 사용하는 빈은 제외하고, 내가 등록한 빈만 출력해보자.
  • 스프링이 내부에서 사용하는 빈은 getRole() 로 구분할 수 있다.
  • ROLE_APPLICATION : 일반적으로 사용자가 정의한 빈
  • ROLE_INFRASTRUCTURE : 스프링이 내부에서 사용하는 빈
@Test
@DisplayName("애플리케이션 빈 출력하기")
void findApplicationBean(){
    String[] beanDefinitionNames = ac.getBeanDefinitionNames();
    for (String beanDefinitionName : beanDefinitionNames) {
        BeanDefinition beanDefinition = ac.getBeanDefinition(beanDefinitionName);

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

 

스프링 빈 조회 

기본

package hello.core.beanfind;

import hello.core.AppConfig;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.NoSuchBeanDefinitionException;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

import static org.assertj.core.api.Assertions.*;

public class ApplicationContextBasicFindTest {
    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    @Test
    @DisplayName("빈 이름과 타입으로 조회")
    void findBeanByName(){
        MemberService memberService = ac.getBean("memberService", MemberService.class); //여기서 MemberService는 인터페이스
        assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }

    @Test
    @DisplayName("이름 없이 타입으로 조회")
    void findBeanByType() {
        MemberService memberService = ac.getBean(MemberService.class); //여기서 MemberService는 인터페이스
        assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }

    @Test
    @DisplayName("구체 타입으로 조회")
    void findBeanByName2() {
        MemberServiceImpl memberService = ac.getBean("memberService", MemberServiceImpl.class); //여기서 MemberServiceImpl은 인터페이스의 구현체
        assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }

    //실패 테스트 케이스
    @Test
    @DisplayName("빈 이름으로 조회X")
    void findBeanByNameX() {
        //ac.getBean("xxxxx", MemberService.class);
        //ac.getBean("xxxxx", MemberService.class) 이 코드를 실행했을 때 NoSuchBeanDefinitionException 예외가 발생하는지 테스트
        Assertions.assertThrows(NoSuchBeanDefinitionException.class, () ->
                ac.getBean("xxxxx", MemberService.class));
    }
}
참고
구체 타입으로 조회하면 변경시 유연성이 떨어진다.

스프링 컨테이너에서 스프링 빈을 찾는 가장 기본적인 조회 방법

  • ac.getBean(빈이름, 타입)
  • ac.getBean(타입)

 

조회 대상 스프링 빈이 없으면 예외 발생
-> NoSuchBeanDefinitionException: No bean named 'xxxxx' available

 

동일한 타입이 둘 이상

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

import hello.core.member.MemberRepository;
import hello.core.member.MemoryMemberRepository;
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;

import static org.assertj.core.api.Assertions.assertThat;

public class ApplicationContextSameBeanFindTest {
    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(sameBeanConfig.class);

    @Configuration
    static class sameBeanConfig{

        @Bean
        public MemberRepository memberRepository1(){
            return new MemoryMemberRepository();
        }

        @Bean
        public MemberRepository memberRepository2(){
            return new MemoryMemberRepository();
        }
    }

    @Test
    @DisplayName("타입으로 조회시 같은 타입이 둘 이상 있으면, 중복 오류가 발생한다")
    void findBeanByTypeDuplicate() {
        //MemberRepository bean = ac.getBean(MemberRepository.class); - MemberRepository에 리턴하는 값이 중복된 것이 있으므로 오류 발생

        //ac.getBean(MemberRepository.class) 코드를 실행하면 NoUniqueBeanDefinitionException 예외가 발생하는지 테스트
        Assertions.assertThrows(NoUniqueBeanDefinitionException.class, () ->
                ac.getBean(MemberRepository.class));
    }

    @Test
    @DisplayName("타입으로 조회시 같은 타입이 둘 이상 있으면, 빈 이름을 지정하면 된다")
    void findBeanByName(){
        MemberRepository memberRepository = ac.getBean("memberRepository1", MemberRepository.class);
        assertThat(memberRepository).isInstanceOf(MemberRepository.class);
    }

    @Test
    @DisplayName("특정 타입을 모두 조회하기")
    void findAllBeanByType(){
        Map<String, MemberRepository> beansOfType = ac.getBeansOfType(MemberRepository.class);
        for (String key : beansOfType.keySet()) {
            System.out.println("key = " + beansOfType + " value = " +beansOfType.get(key));
            assertThat(beansOfType.size()).isEqualTo(2);
        }
    }
    //key = {memberRepository1=hello.core.member.MemoryMemberRepository@7a356a0d, memberRepository2=hello.core.member.MemoryMemberRepository@c827db} value = hello.core.member.MemoryMemberRepository@7a356a0d
    //key = {memberRepository1=hello.core.member.MemoryMemberRepository@7a356a0d, memberRepository2=hello.core.member.MemoryMemberRepository@c827db} value = hello.core.member.MemoryMemberRepository@c827db
}
static class는 아래의 링크에서 정적 멤버 클래스 부분을 참고하면 된다.

2023.01.12 - [Java Category/Java] - [JAVA] 중첩 클래스(Nested Class)

 

스프링 빈 조회 - 상속 관계

  • 부모 타입으로 조회하면, 자식 타입도 함께 조회한다.
  • 그래서 모든 자바 객체의 최고 부모인 Object 타입으로 조회하면, 모든 스프링 빈을 조회한다.

package hello.core.beanfind;
import hello.core.discount.DiscountPolicy;
import hello.core.discount.FixDiscountPolicy;
import hello.core.discount.RateDiscountPolicy;
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.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import java.util.Map;
import static org.assertj.core.api.Assertions.assertThat;
import static org.junit.jupiter.api.Assertions.assertThrows;
class ApplicationContextExtendsFindTest {
    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class);

    @Configuration
    static class TestConfig {
        @Bean
        public DiscountPolicy rateDiscountPolicy() {
            return new RateDiscountPolicy();
        }
        @Bean
        public DiscountPolicy fixDiscountPolicy() {
            return new FixDiscountPolicy();
        }
    }

    @Test
    @DisplayName("부모 타입으로 조회시, 자식이 둘 이상 있으면, 중복 오류가 발생한다")
    void findBeanByParentTypeDuplicate() {
        //DiscountPolicy bean = ac.getBean(DiscountPolicy.class); //DiscountPolicy를 구현하는 클래스가 2개임

        //ac.getBean(DiscountPolicy.class) 코드를 실행하면 NoUniqueBeanDefinitionException 예외가 발생하는지 테스트
        assertThrows(NoUniqueBeanDefinitionException.class, () ->
                ac.getBean(DiscountPolicy.class));
    }
    @Test
    @DisplayName("부모 타입으로 조회시, 자식이 둘 이상 있으면, 빈 이름을 지정하면 된다")
    void findBeanByParentTypeBeanName() {
        DiscountPolicy rateDiscountPolicy = ac.getBean("rateDiscountPolicy", DiscountPolicy.class); //DiscountPolicy 구현하는 클래스 중 특정 클래스 선택
        assertThat(rateDiscountPolicy).isInstanceOf(RateDiscountPolicy.class);
    }
    
    @Test
    @DisplayName("특정 하위 타입으로 조회")
    void findBeanBySubType() {
        RateDiscountPolicy bean = ac.getBean(RateDiscountPolicy.class);
        assertThat(bean).isInstanceOf(RateDiscountPolicy.class);
    }
    @Test
    @DisplayName("부모 타입으로 모두 조회하기")
    void findAllBeanByParentType() {
        Map<String, DiscountPolicy> beansOfType = ac.getBeansOfType(DiscountPolicy.class);
        assertThat(beansOfType.size()).isEqualTo(2);
        for (String key : beansOfType.keySet()) {
            System.out.println("key = " + key + " value=" + beansOfType.get(key));
        }
    }
    //key = rateDiscountPolicy value=hello.core.discount.RateDiscountPolicy@12477988
    //key = fixDiscountPolicy value=hello.core.discount.FixDiscountPolicy@2caf6912

    @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));
        }
    }
    //key = org.springframework.context.annotation.internalConfigurationAnnotationProcessor value=org.springframework.context.annotation.ConfigurationClassPostProcessor@377c68c6
    //key = org.springframework.context.annotation.internalAutowiredAnnotationProcessor value=org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor@538cd0f2
    //key = org.springframework.context.annotation.internalCommonAnnotationProcessor value=org.springframework.context.annotation.CommonAnnotationBeanPostProcessor@238ad8c
    //key = org.springframework.context.event.internalEventListenerProcessor value=org.springframework.context.event.EventListenerMethodProcessor@430fa4ef
    //key = org.springframework.context.event.internalEventListenerFactory value=org.springframework.context.event.DefaultEventListenerFactory@1761de10
    //....
}

 

BeanFactory와 ApplicationContext

BeanFactory

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

ApplicationContext

  • BeanFactory 기능을 모두 상속받아서 제공한다.
  • BeanFactory 의 기본적인 기능 이외에 부가적인 기능을 제공

 

ApplicatonContext가 제공하는 부가기능

  • 메시지소스를 활용한 국제화 기능 : 예를 들어서 한국에서 들어오면 한국어로, 영어권에서 들어오면 영어로 출력
  • 환경변수 : 로컬, 개발, 운영등을 구분해서 처리
  • 애플리케이션 이벤트 : 이벤트를 발행하고 구독하는 모델을 편리하게 지원
  • 편리한 리소스 조회 : 파일, 클래스패스, 외부 등에서 리소스를 편리하게 조회
정리
-ApplicationContext는 BeanFactory의 기능을 상속받는다.
-ApplicationContext는 빈 관리기능 + 편리한 부가 기능을 제공한다.
-BeanFactory를 직접 사용할 일은 거의 없다. 부가기능이 포함된 ApplicationContext를 사용한다.
-BeanFactory나 ApplicationContext를 스프링 컨테이너라 한다

 

다양한 설정 형식 지원 - 자바 코드, XML

스프링 컨테이너는 다양한 형식의 설정 정보를 받아들일 수 있게 유연하게 설계되어 있다.

자바 코드, XML, Groovy 등등

어노테이션 기반 자바 코드 설정 사용

  • new AnnotationConfigApplicationContext(AppConfig.class)
  • AnnotationConfigApplicationContext 클래스를 사용하면서 자바 코드로된 설정 정보를 넘기면 된다.

 

XML 설정 사용

  • 최근에는 스프링 부트를 많이 사용하면서 XML기반의 설정은 잘 사용하지 않는다. 아직 많은 레거시 프로젝트 들이 XML로 되어 있고, 또 XML을 사용하면 컴파일 없이 빈 설정 정보를 변경할 수 있는 장점도 있으므로 한번쯤 배워두는 것도 괜찮다.
  • GenericXmlApplicationContext 를 사용하면서 xml 설정 파일을 넘기면 된다.

package hello.core.xml;

import hello.core.member.MemberService;
import org.junit.jupiter.api.Test;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.GenericXmlApplicationContext;

import static org.assertj.core.api.Assertions.*;
public class XmlAppContext {
    @Test
    void xmlAppContext() {
    	//xml 파일을 기반으로 스프링 컨테이너에 자바빈을 등록
        ApplicationContext ac = new GenericXmlApplicationContext("appConfig.xml");

        MemberService memberService = ac.getBean("memberService", MemberService.class);
        assertThat(memberService).isInstanceOf(MemberService.class);
    }
}

 

xml 기반의 스프링 빈 설정 정보

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean id="memberService" class="hello.core.member.MemberServiceImpl">
        <constructor-arg name="memberRepository" ref="memberRepository" />
    </bean>
    
    <bean id="memberRepository" class="hello.core.member.MemoryMemberRepository" />
    
    <bean id="orderService" class="hello.core.order.OrderServiceImpl">
        <constructor-arg name="memberRepository" ref="memberRepository" />
        <constructor-arg name="discountPolicy" ref="discountPolicy" />
    </bean>
    
    <bean id="discountPolicy" class="hello.core.discount.RateDiscountPolicy" />
</beans>

xml 기반의 appConfig.xml 스프링 설정 정보와 자바 코드로 된 AppConfig.java 설정 정보를 비교해보면 거의 비슷하다는 것을 알 수 있다.

스프링 공식 레퍼런스 문서 주소는 아래와 같다.

https://spring.io/projects/spring-framework

 

스프링 빈 설정 메타 정보 - BeanDefinition

스프링은 어떻게 이런 다양한 설정 형식을 지원하는 것일까?

  • 그 중심에는 BeanDefinition 이라는 추상화가있다.
  • 쉽게 이야기해서 역할과 구현을 개념적으로 나눈 것이다.
    -XML을 읽어서 BeanDefinition을 만들면 된다.
    -자바 코드를 읽어서 BeanDefinition을 만들면 된다.
    -스프링 컨테이너는 자바 코드인지, XML인지 몰라도 된다. 오직 BeanDefinition만 알면 된다.
  • BeanDefinition 을 빈 설정 메타정보라 한다.
    -@Bean , <bean> 당 각각 하나씩 메타 정보가 생성된다.
  • 스프링 컨테이너는 이 메타정보를 기반으로 스프링 빈을 생성한다.

 

  • AnnotationConfigApplicationContext 는 AnnotatedBeanDefinitionReader 를 사용해서 AppConfig.class 를 읽고 BeanDefinition 을 생성한다.
  • GenericXmlApplicationContext 는 XmlBeanDefinitionReader 를 사용해서 appConfig.xml 설정 정보를 읽고 BeanDefinition 을 생성한다.
  • 새로운 형식의 설정 정보가 추가되면, XxxBeanDefinitionReader를 만들어서 BeanDefinition 을 생성하면 된다.

 

BeanDefinition 정보

  • BeanClassName: 생성할 빈의 클래스 명(자바 설정 처럼 팩토리 역할의 빈을 사용하면 없음)
  • factoryBeanName: 팩토리 역할의 빈을 사용할 경우 이름, 예) appConfig
  • factoryMethodName: 빈을 생성할 팩토리 메서드 지정, 예) memberService
  • Scope: 싱글톤(기본값)
  • lazyInit: 스프링 컨테이너를 생성할 때 빈을 생성하는 것이 아니라, 실제 빈을 사용할 때 까지 최대한 생성을 지연 처리 하는지 여부
  • InitMethodName: 빈을 생성하고, 의존관계를 적용한 뒤에 호출되는 초기화 메서드 명
  • DestroyMethodName: 빈의 생명주기가 끝나서 제거하기 직전에 호출되는 메서드 명
  • Constructor arguments, Properties: 의존관계 주입에서 사용한다. (자바 설정 처럼 팩토리 역할의 빈을 사용하면 없음)
package hello.core.beandefinition;
import hello.core.AppConfig;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.beans.MutablePropertyValues;
import org.springframework.beans.factory.config.BeanDefinition;
import org.springframework.beans.factory.config.ConstructorArgumentValues;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.support.GenericXmlApplicationContext;
public class BeanDefinitionTest {
    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class); //팩토리 메서드를 통해 스프링 컨테이너에 등록
    //GenericXmlApplicationContext ac = newGenericXmlApplicationContext("appConfig.xml"); //직접 스프링 빈을 스프링 컨테이너에 등록

    @Test
    @DisplayName("빈 설정 메타정보 확인")
    void findApplicationBean() {
        String[] beanDefinitionNames = ac.getBeanDefinitionNames();
        for (String beanDefinitionName : beanDefinitionNames) {
            BeanDefinition beanDefinition = ac.getBeanDefinition(beanDefinitionName);
            if (beanDefinition.getRole() == BeanDefinition.ROLE_APPLICATION) {
                System.out.println("beanDefinitionName" + beanDefinitionName + " beanDefinition = " + beanDefinition);
            }
        }
    }
}

이 글은 인프런 김영한님의 Spring 강의를 바탕으로 개인적인 정리를 위해 작성한 글입니다.


새로운 할인 정책 개발

새로운 할인 정책을 확장해보자.

악덕 기획자가 서비스 오픈 직전에 할인 정책을 변경하고 싶어한다.

기존에는 VIP 고객이 주문 금액에 관계없이 일정 금액(예: 1000원)을 할인받는 방식이었지만, 이제 주문 금액의 일정 비율(예: 10%)을 할인하는 방식으로 변경하고자 한다.

순진 개발자는 처음부터 고정 금액 할인 방식에 반대했지만, 악덕 기획자는 애자일 개발 방식을 인용하며 변화에 대응할 것을 주장한다.

순진 개발자는 유연한 설계를 위해 객체지향 설계 원칙을 이미 준수했기 때문에 상관없다고 생각한다.

 

순진 개발자가 정말 객체지향 설계 원칙을 잘 준수 했는지 확인해보자. 이번에는 주문한 금액의 %를 할인해주는 새로운
정률 할인 정책을 추가하자.

 

RateDiscountPolicy 추가

RateDiscountPolicy 코드 추가

package hello.core.discount;

import hello.core.member.Grade;
import hello.core.member.Member;

public class RateDiscountPolicy implements DiscountPolicy{
    private int discountPercent = 10; //10% 할인
    @Override
    public int discount(Member member, int price) {
        if (member.getGrade() == Grade.VIP){
            return price * discountPercent / 100;
        }else {
            return 0;
        }
    }
}

 

테스트 작성

package hello.core.discount;

import hello.core.member.Grade;
import hello.core.member.Member;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import static org.assertj.core.api.Assertions.*;

public class RateDiscountPolicyTest {
    RateDiscountPolicy discountPolicy = new RateDiscountPolicy();

    @Test
    @DisplayName("VIP는 10% 할인")
    void vip_o(){
        //given
        Member member = new Member(1L, "memverVIP", Grade.VIP);
        //when
        int discount = discountPolicy.discount(member, 10000);
        //then
        Assertions.assertThat(discount).isEqualTo(1000);
    }

    @Test
    @DisplayName("VIP가 아니면 할인 없음")
    void vip_x(){
        //given
        Member member = new Member(2L, "memberBASIC", Grade.BASIC);
        //when
        int discount = discountPolicy.discount(member, 10000);
        //then
        assertThat(discount).isEqualTo(0);
    }
}

 

새로운 할인 정책 적용과 문제점

할인 정책을 변경하려면 클라이언트인 OrderServiceImpl 코드를 고쳐야 한다.

public class OrderServiceImpl implements OrderService {
// private final DiscountPolicy discountPolicy = new FixDiscountPolicy();
 private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
}
  • 우리는 역할과 구현을 충실하게 분리했다. OK
  • 다형성도 활용하고, 인터페이스와 구현 객체를 분리했다. OK
  • OCP, DIP 같은 객체지향 설계 원칙을 충실히 준수했다.(그렇게 보이지만 사실은 아니다.)
  • DIP: 주문서비스 클라이언트( OrderServiceImpl )는 DiscountPolicy 인터페이스에 의존하면서 DIP를
    지킨 것 같은데, 클래스 의존관계를 분석해 보면 추상(인터페이스) 뿐만 아니라 구체(구현) 클래스에도 의존하고 있다.
    - 추상(인터페이스) 의존: DiscountPolicy
    - 구체(구현) 클래스: FixDiscountPolicy , RateDiscountPolicy
  • OCP: 변경하지 않고 확장할 수 있다고 했는데, 지금 코드는 기능을 확장해서 변경하면, 클라이언트 코드에 영향을 준다! 따라서 OCP를 위반한다.

 

기대했던 의존관계

지금까지 단순히 DiscountPolicy 인터페이스만 의존한다고 생각했다

 

실제 의존관계

잘보면 클라이언트인 OrderServiceImpl 이 DiscountPolicy 인터페이스 뿐만 아니라 FixDiscountPolicy 인 구체 클래스도 함께 의존하고 있다.

실제 코드를 보면 의존하고 있다. -> DIP 위반

 

그래서 FixDiscountPolicy 를 RateDiscountPolicy 로 변경하는 순간 OrderServiceImpl 의 소스 코드도 함께 변경해야 한다. -> OCP 위반

 

문제 해결 방법

  • 클라이언트 코드인 OrderServiceImpl 은 DiscountPolicy 의 인터페이스 뿐만 아니라 구체 클래스도 함
    께 의존한다.
  • 그래서 구체 클래스를 변경할 때 클라이언트 코드도 함께 변경해야 한다.
  • DIP 위반 추상에만 의존하도록 변경(인터페이스에만 의존)
  • DIP를 위반하지 않도록 인터페이스에만 의존하도록 의존관계를 변경하면 된다

 

인터페이스에만 의존하도록 의존관계를 변경해야 한다

public class OrderServiceImpl implements OrderService {
 //private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
 private DiscountPolicy discountPolicy;
}
  • 인터페이스에만 의존하도록 설계와 코드를 변경했다. 하지만 구현체가 없기 때문에 실행할 수 없다.
  • 실제 실행을 해보면 NPE(null pointer exception)가 발생한다.

 

이 문제를 해결하려면 누군가가 클라이언트인 OrderServiceImpl 에 DiscountPolicy 의 구현 객체를 대신 생성하고 주입해주어야 한다. -> 이후에 등장하는 AppConfig 클래스의 등장으로 해결

 

관심사의 분리

애플리케이션을 하나의 공연이라 생각해보자.

각각의 인터페이스를 배역(배우 역할)이라 생각하자.

그런데 배역 맞는 배우를 선택하는 것은 누가 하는가?

로미오와 줄리엣 공연을 하면 로미오 역할을 누가 할지 줄리엣 역할을 누가 할지는 배우들이 정하는게 아니다.

이전 코드는 마치 로미오 역할(인터페이스)을 하는 레오나르도 디카프리오(구현체, 배우)가 줄리엣 역할(인터페이스)을 하는 여자 주인공(구현체, 배우)을 직접 초빙하는 것과 같다.

 

디카프리오는 공연도 해야하고 동시에 여자 주인공도 공연에 직접 초빙해야 하는 다양한 책임을 가지고 있다.

배우는 본인의 역할인 배역을 수행하는 것에만 집중해야 한다.

디카프리오는 어떤 여자 주인공이 선택되더라도 똑같이 공연을 할 수 있어야 한다.

 

공연을 구성하고, 담당 배우를 섭외하고, 역할에 맞는 배우를 지정하는 책임을 담당하는 별도의 공연 기획자가 나
올시점이다.

공연 기획자를 만들고, 배우와 공연 기획자의 책임을 확실히 분리하자.

 

Appconfig 등장

애플리케이션의 전체 동작 방식을 구성(config)하기 위해, 구현 객체를 생성하고, 연결하는 책임을 가지는 별도의 설정 클래스를 만들자.

package hello.core;
import hello.core.discount.FixDiscountPolicy;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import hello.core.member.MemoryMemberRepository;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;
public class AppConfig {
    public MemberService memberService() {
        return new MemberServiceImpl(new MemoryMemberRepository());
    }
    public OrderService orderService() {
        return new OrderServiceImpl(new MemoryMemberRepository(), new FixDiscountPolicy());
    }
}

지금은 각 클래스에 생성자가 없어서 컴파일 오류가 발생한다. 바로 다음에 코드에서 생성자를 만든다

 

  • AppConfig는 애플리케이션의 실제 동작에 필요한 구현 객체를 생성한다.
    -MemberServiceImpl
    -MemoryMemberRepository
    -OrderServiceImpl
    -FixDiscountPolicy
  • AppConfig는 생성한 객체 인스턴스의 참조(레퍼런스)를 생성자를 통해서 주입(연결)해준다.
    -MemberServiceImpl -> MemoryMemberRepository
    -OrderServiceImpl -> MemoryMemberRepository , FixDiscountPolicy

 

MemberServiceImpl  수정 (생성자 주입)

package hello.core.member;

public class MemberServiceImpl implements MemberService{
    //private final MemberRepository memberRepository = new MemoryMemberRepository();
    private final MemberRepository memberRepository;

    public MemberServiceImpl(MemberRepository memberRepository){
        this.memberRepository = memberRepository;
    }
    @Override
    public void join(Member member) {
        memberRepository.save(member);
    }
    @Override
    public Member findMember(long memberId) {
        return memberRepository.findById(memberId);
    }
}
  • 설계 변경으로 MemberServiceImpl 은 MemoryMemberRepository 를 의존하지 않는다.
    단지 MemberRepository 인터페이스만 의존한다.
  • MemberServiceImpl 입장에서 생성자를 통해 어떤 구현 객체가 들어올지(주입될지)는 알 수 없다.
  • MemberServiceImpl 의 생성자를 통해서 어떤 구현 객체를 주입할지는 오직 외부( AppConfig )에서 결정
    다.
  • MemberServiceImpl 은 이제부터 의존관계에 대한 고민은 외부에 맡기고 실행에만 집중하면 된다.

 

클래스 다이어그램

  • 객체의 생성과 연결은 AppConfig 가 담당한다.
  • DIP 완성: MemberServiceImpl 은 MemberRepository 인 추상에만 의존하면 된다. 이제 구체 클래스를
    몰라도 된다.
  • 관심사의 분리: 객체를 생성하고 연결하는 역할과 실행하는 역할이 명확히 분리되었다.

 

회원 객체 인스턴스 다이어그램

  • appConfig 객체는 memoryMemberRepository 객체를 생성하고 그 참조값을 memberServiceImpl 을
    생성하면서 생성자로 전달한다.
  • 클라이언트인 memberServiceImpl 입장에서 보면 의존관계를 마치 외부에서 주입해주는 것 같다고 해서
    DI(Dependency Injection) 우리말로 의존관계 주입 또는 의존성 주입이라 한다

 

OrderServiceImpl 수정(생성자 주입)

package hello.core.order;

import hello.core.discount.DiscountPolicy;
import hello.core.member.Member;
import hello.core.member.MemberRepository;

public class OrderServiceImpl implements OrderService{
    //private final MemberRepository memberRepository = new MemoryMemberRepository();

    //private  final DiscountPolicy discountPolicy = new RateDiscountPolicy();
    //private  final DiscountPolicy discountPolicy = new FixDiscountPolicy();

    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
    @Override
    public Order createOrder(long memberId, String itemName, int itemPrice) {
        Member member = memberRepository.findById(memberId);
        int discountPrice = discountPolicy.discount(member, itemPrice);

        return new Order(memberId, itemName, itemPrice, discountPrice);
    }
}
  • 설계 변경으로 OrderServiceImpl 은 FixDiscountPolicy 를 의존하지 않는다.
    단지 DiscountPolicy 인터페이스만 의존한다.
  • OrderServiceImpl 입장에서 생성자를 통해 어떤 구현 객체가 들어올지(주입될지)는 알 수 없다.
  • OrderServiceImpl 의 생성자를 통해서 어떤 구현 객체을 주입할지는 오직 외부( AppConfig )에서 결정
    다.
  • OrderServiceImpl 은 이제부터 실행에만 집중하면 된다.
  • OrderServiceImpl 에는 MemoryMemberRepository , FixDiscountPolicy 객체의 의존관계가 주
    입된다.

 

AppConfig 실행

MemberApp

package hello.core;

import hello.core.member.Grade;
import hello.core.member.Member;
import hello.core.member.MemberService;

public class MemberApp {
    public static void main(String[] args) {
        AppConfig appConfig = new AppConfig();
        MemberService memberService = appConfig.memberService();
        Member member = new Member(1L, "memberA", Grade.VIP);
        memberService.join(member);

        Member findMember = memberService.findMember(1L);
        System.out.println("new member = " + member.getName());
        System.out.println("find member = " + findMember.getName());
    }
}

 

OrderApp

package hello.core;

import hello.core.member.Grade;
import hello.core.member.Member;
import hello.core.member.MemberService;
import hello.core.order.Order;
import hello.core.order.OrderService;

public class OrderApp {
    public static void main(String[] args) {
        AppConfig appConfig = new AppConfig();
        MemberService memberService = appConfig.memberService();
        OrderService orderService = appConfig.orderService();

        long memberId = 1L;
        Member member = new Member(memberId, "memberA", Grade.VIP);
        memberService.join(member);

        Order order = orderService.createOrder(memberId, "itemA", 10000);
        System.out.println("order = " + order);
    }
}

 

MemberServiceTest

package hello.core.member;

import hello.core.AppConfig;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;

public class MemberServiceTest {
    MemberService memberService;

    @BeforeEach
    public void beforeEach(){
        AppConfig appConfig = new AppConfig();
        memberService = appConfig.memberService();
    }

    @Test
    void join(){
        //given
        Member member = new Member(1L, "memberA", Grade.VIP);
        //when
        memberService.join(member);
        Member findeMember = memberService.findMember(1L);
        //then
        Assertions.assertThat(member).isEqualTo(findeMember);
    }
}

 

OrderServiceTest

package hello.core.order;

import hello.core.AppConfig;
import hello.core.member.Grade;
import hello.core.member.Member;
import hello.core.member.MemberService;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;

public class OrderServiceTest {
    MemberService memberService;
    OrderService orderService;
    @BeforeEach
    public void beforeEach() {
        AppConfig appConfig = new AppConfig();
        memberService = appConfig.memberService();
        orderService = appConfig.orderService();
    }

    @Test
    void createOrder(){
        long memberId = 1L;
        Member member = new Member(memberId, "memberA", Grade.VIP);
        memberService.join(member);

        Order order = orderService.createOrder(memberId, "itemA", 10000);
        Assertions.assertThat(order.getDiscountPrice()).isEqualTo(1000);
    }
}

 

정리

-AppConfig를 통해서 관심사를 확실하게 분리했다.
-배역, 배우를 생각해보자.
-AppConfig는 공연 기획자다. 
-AppConfig는 구체 클래스를 선택한다. 배역에 맞는 담당 배우를 선택한다. 애플리케이션이 어떻게 동작해야 할
지 전체 구성을 책임진다.
-이제 각 배우들은 담당 기능을 실행하는 책임만 지면 된다.
-OrderServiceImpl 은 기능을 실행하는 책임만 지면 된다.

 

AppConfig 리팩터링

현재 AppConfig를 보면 중복이 있고, 역할에 따른 구현이 잘 안보인다.

기대한 그림

리팩터링 전

package hello.core;
import hello.core.discount.FixDiscountPolicy;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import hello.core.member.MemoryMemberRepository;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;
public class AppConfig {
    public MemberService memberService() {
        return new MemberServiceImpl(new MemoryMemberRepository());
    }
    public OrderService orderService() {
        return new OrderServiceImpl(new MemoryMemberRepository(), new FixDiscountPolicy());
    }
}

 

중복을 제거하고, 역할에 따른 구현이 보이도록 리팩터링 하자.

인텔리제이에서 리팩터링 기능
리팩터링 하고싶은 코드를 드래그한다.

윈도우 기준 ctrl + alt + m 을 누른다.
톱니바퀴 버튼을 누른다.
이름과 리턴 타입을 지정해준다.

 

리팩터링 후

package hello.core;
import hello.core.discount.DiscountPolicy;
import hello.core.discount.FixDiscountPolicy;
import hello.core.member.MemberRepository;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import hello.core.member.MemoryMemberRepository;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;
public class AppConfig {
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }

    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }

    public OrderService orderService() {
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }

    private DiscountPolicy discountPolicy() {
        return new FixDiscountPolicy();
    }
}

 

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

 

새로운 구조와 할인 정책 적용

  • 처음으로 돌아가서 정액 할인 정책을 정률% 할인 정책으로 변경해보자.
  • FixDiscountPolicy -> RateDiscountPolicy
package hello.core;
import hello.core.discount.DiscountPolicy;
import hello.core.discount.RateDiscountPolicy;
import hello.core.member.MemberRepository;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import hello.core.member.MemoryMemberRepository;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;
public class AppConfig {
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }

    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }

    public OrderService orderService() {
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }

    public DiscountPolicy discountPolicy() {
        //return new FixDiscountPolicy();
        return  new RateDiscountPolicy();
    }
}

 

AppConfig의 등장으로 애플리케이션이 크게 사용 영역과, 객체를 생성하고 구성(Configuration)하는 영역으로 분리되었다.

FixDiscountPolicy -> RateDiscountPolicy 로 변경해도 구성 영역만 영향을 받고, 사용 영역은 전혀 영향을 받지 않는다.

AppConfig 에서 할인 정책 역할을 담당하는 구현을 FixDiscountPolicy RateDiscountPolicy 객체로 변경했다.

이제 할인 정책을 변경해도, 애플리케이션의 구성 역할을 담당하는 AppConfig만 변경하면 된다. 클라이언트 코드인 OrderServiceImpl 를 포함해서 사용 영역의 어떤 코드도 변경할 필요가 없다.

구성 영역은 당연히 변경된다. 구성 역할을 담당하는 AppConfig를 애플리케이션이라는 공연의 기획자로 생각하자. 공연 기획자는 공연 참여자인 구현 객체들을 모두 알아야 한다.

 

전체 흐름 정리

새로운 할인 정책 개발

  • 다형성 덕분에 새로운 정률 할인 정책 코드를 추가로 개발하는 것 자체는 아무 문제가 없음

 

새로운 할인 정책 적용과 문제점

  • 새로 개발한 정률 할인 정책을 적용하려고 하니 클라이언트 코드인 주문 서비스 구현체도 함께 변경해야함
    주문 서비스 클라이언트가 인터페이스인 DiscountPolicy 뿐만 아니라, 구체 클래스인 FixDiscountPolicy 도 함께 의존 -> DIP 위반

 

관심사의 분리

  • 애플리케이션을 하나의 공연으로 생각
  • 기존에는 클라이언트가 의존하는 서버 구현 객체를 직접 생성하고, 실행함
  • 비유를 하면 기존에는 남자 주인공 배우가 공연도 하고, 동시에 여자 주인공도 직접 초빙하는 다양한 책임을 가지고 있음
  • 공연을 구성하고, 담당 배우를 섭외하고, 지정하는 책임을 담당하는 별도의 공연 기획자가 나올 시점
  • 공연 기획자인 AppConfig가 등장
  • AppConfig는 애플리케이션의 전체 동작 방식을 구성(config)하기 위해, 구현 객체를 생성하고, 연결하는 책임
  • 이제부터 클라이언트 객체는 자신의 역할을 실행하는 것만 집중, 권한이 줄어듬(책임이 명확해짐)

 

AppConfig 리팩터링

  • 구성 정보에서 역할과 구현을 명확하게 분리
  • 역할이 잘 드러남
  • 중복 제거

 

새로운 구조와 할인 정책 적용

  • 정액 할인 정책 정률% 할인 정책으로 변경
  • AppConfig의 등장으로 애플리케이션이 크게 사용 영역과, 객체를 생성하고 구성(Configuration)하는 영역으로 분리
  • 할인 정책을 변경해도 AppConfig가 있는 구성 영역만 변경하면 됨, 사용 영역은 변경할 필요가 없음. 물론 클라이언트 코드인 주문 서비스 코드도 변경하지 않음

 

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

SRP 단일 책임 원칙

  • 한 클래스는 하나의 책임만 가져야 한다.
  • 클라이언트 객체는 직접 구현 객체를 생성하고, 연결하고, 실행하는 다양한 책임을 가지고 있음
  • SRP 단일 책임 원칙을 따르면서 관심사를 분리함
  • 구현 객체를 생성하고 연결하는 책임은 AppConfig가 담당
  • 클라이언트 객체는 실행하는 책임만 담당

 

DIP 의존관계 역전 원칙

  • 프로그래머는 “추상화에 의존해야지, 구체화에 의존하면 안된다.” 의존성 주입은 이 원칙을 따르는 방법 중 하나다.
  • 새로운 할인 정책을 개발하고, 적용하려고 하니 클라이언트 코드도 함께 변경해야 했다. 왜냐하면 기존 클라이언트 코드( OrderServiceImpl )는 DIP를 지키며 DiscountPolicy 추상화 인터페이스에 의존하는 것 같았지만, FixDiscountPolicy 구체화 구현 클래스에도 함께 의존했다.
  • 클라이언트 코드가 DiscountPolicy 추상화 인터페이스에만 의존하도록 코드를 변경했다.
    하지만 클라이언트 코드는 인터페이스만으로는 아무것도 실행할 수 없다.
  • AppConfig가 FixDiscountPolicy 객체 인스턴스를 클라이언트 코드 대신 생성해서 클라이언트 코드에 의
    존관계를 주입했다. 이렇게해서 DIP 원칙을 따르면서 문제도 해결했다.

 

OCP

  • 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다
  • 다형성 사용하고 클라이언트가 DIP를 지킴
  • 애플리케이션을 사용 영역과 구성 영역으로 나눔
  • AppConfig가 의존관계를 FixDiscountPolicy RateDiscountPolicy 로 변경해서 클라이언트 코드에 주입하므로 클라이언트 코드는 변경하지 않아도 됨
  • 소프트웨어 요소를 새롭게 확장해도 사용 영역의 변경은 닫혀 있다.

 

IoC, DI 그리고 컨테이너

제어의 역전 IoC(Inversion of Control)

  • 기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성하고, 연결하고, 실행했다. 한마디
    로 구현 객체가 프로그램의 제어 흐름을 스스로 조종했다. 개발자 입장에서는 자연스러운 흐름이다.
  • 반면에 AppConfig가 등장한 이후에 구현 객체는 자신의 로직을 실행하는 역할만 담당한다. 프로그램의 제어 흐
    름은 이제 AppConfig가 가져간다. 예를 들어서 OrderServiceImpl 은 필요한 인터페이스들을 호출하지만 어떤 구현 객체들이 실행될지 모른다. 
  • 프로그램에 대한 제어 흐름에 대한 권한은 모두 AppConfig가 가지고 있다. 심지어 OrderServiceImpl 도
    AppConfig가 생성한다. 그리고 AppConfig는 OrderServiceImpl 이 아닌 OrderService 인터페이스의
    다른 구현 객체를 생성하고 실행할 수 도 있다. 
    그런 사실도 모른체 OrderServiceImpl 은 묵묵히 자신의 로직
    을 실행할 뿐이다.
  • 이렇듯 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전(IoC)이라 한다.

프레임워크 vs 라이브러리

-프레임워크가 내가 작성한 코드를 제어하고, 대신 실행하면 그것은 프레임워크가 맞다. (JUnit)
-반면에 내가 작성한 코드가 직접 제어의 흐름을 담당한다면 그것은 프레임워크가 아니라 라이브러리다.

 

의존관계 주입 DI(Dependency Injection)

  • OrderServiceImpl 은 DiscountPolicy 인터페이스에 의존한다. 실제 어떤 구현 객체가 사용될지는 모른
    다.
  • 의존관계는 정적인 클래스 의존 관계와, 실행 시점에 결정되는 동적인 객체(인스턴스) 의존 관계 둘을 분리해서 생
    각해야 한다. 

정적인 클래스 의존관계

클래스가 사용하는 import 코드만 보고 의존관계를 쉽게 판단할 수 있다. 정적인 의존관계는 애플리케이션을 실행하지
않아도 분석할 수 있다.


OrderServiceImpl 은 MemberRepository , DiscountPolicy 에 의존한다는 것을 알 수 있다.
그런데 이러한 클래스 의존관계 만으로는 실제 어떤 객체가 OrderServiceImpl 에 주입 될지 알 수 없다.

 

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

애플리케이션 실행 시점에 실제 생성된 객체 인스턴스의 참조가 연결된 의존 관계다.

 

객체 다이어그램

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

객체 인스턴스를 생성하고, 그 참조값을 전달해서 연결된다.

의존관계 주입을 사용하면 클라이언트 코드를 변경하지 않고, 클라이언트가 호출하는 대상의 타입 인스턴스를 변경할 수 있다.

의존관계 주입을 사용하면 정적인 클래스 의존관계를 변경하지 않고, 동적인 객체 인스턴스 의존관계를 쉽게 변경 할 수 있다.

 

IoC 컨테이너, DI 컨테이너

AppConfig 처럼 객체를 생성하고 관리하면서 의존관계를 연결해 주는 것을 IoC 컨테이너 또는 DI 컨테이너라 한다. 
의존관계 주입에 초점을 맞추어 최근에는 주로 DI 컨테이너라 한다.
또는 어샘블러, 오브젝트 팩토리 등으로 불리기도 한다.

 

스프링으로 전환하기

AppConfig를 스프링 기반으로 변경

package hello.core;
import hello.core.discount.DiscountPolicy;
import hello.core.discount.RateDiscountPolicy;
import hello.core.member.MemberRepository;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import hello.core.member.MemoryMemberRepository;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class AppConfig {

    @Bean
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }

    @Bean
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }

    @Bean
    public OrderService orderService() {
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }

    @Bean
    public DiscountPolicy discountPolicy() {
        //return new FixDiscountPolicy();
        return  new RateDiscountPolicy();
    }
}

AppConfig에 설정을 구성한다는 뜻의 @Configuration 을 붙여준다.
각 메서드에 @Bean 을 붙여준다. 이렇게 하면 스프링 컨테이너에 스프링 빈으로 등록한다.

 

MemberApp에 스프링 컨테이너 적용

package hello.core;

import hello.core.member.Grade;
import hello.core.member.Member;
import hello.core.member.MemberService;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

public class MemberApp {
    public static void main(String[] args) {
        // AppConfig appConfig = new AppConfig();
        // MemberService memberService = appConfig.memberService();
        ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService = applicationContext.getBean("memberService", MemberService.class);
        Member member = new Member(1L, "memberA", Grade.VIP);
        memberService.join(member);

        Member findMember = memberService.findMember(1L);
        System.out.println("new member = " + member.getName());
        System.out.println("find member = " + findMember.getName());
    }
}

 

OrderApp에 스프링 컨테이너 적용

package hello.core;

import hello.core.member.Grade;
import hello.core.member.Member;
import hello.core.member.MemberService;
import hello.core.order.Order;
import hello.core.order.OrderService;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

public class OrderApp {
    public static void main(String[] args) {
        // AppConfig appConfig = new AppConfig();
        // MemberService memberService = appConfig.memberService();
        // OrderService orderService = appConfig.orderService();
        ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService = applicationContext.getBean("memberService", MemberService.class);
        OrderService orderService = applicationContext.getBean("orderService", OrderService.class);

        long memberId = 1L;
        Member member = new Member(memberId, "memberA", Grade.VIP);
        memberService.join(member);

        Order order = orderService.createOrder(memberId, "itemA", 10000);
        System.out.println("order = " + order);
    }
}

 

스프링 컨테이너

ApplicationContext 를 스프링 컨테이너라 한다.

기존에는 개발자가 AppConfig 를 사용해서 직접 객체를 생성하고 DI를 했지만, 이제부터는 스프링 컨테이너를
통해서 사용한다.

 

스프링 컨테이너는 @Configuration 이 붙은 AppConfig 를 설정(구성) 정보로 사용한다.

 

여기서 @Bean 이라 적힌 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록한다. 이렇게 스프링 컨테이너에 등록된 객체를 스프링 빈이라 한다.

 

스프링 빈은 @Bean 이 붙은 메서드의 명을 스프링 빈의 이름으로 사용한다.( memberService , orderService )

이전에는 개발자가 필요한 객체를 AppConfig 를 사용해서 직접 조회했지만, 이제부터는 스프링 컨테이너를 통해서 필요한 스프링 빈(객체)를 찾아야 한다.

 

스프링 빈은 applicationContext.getBean() 메서드를 사용해서 찾을 수 있다.

 

기존에는 개발자가 직접 자바코드로 모든 것을 했다면 이제부터는 스프링 컨테이너에 객체를 스프링 빈으로 등록
하고, 스프링 컨테이너에서 스프링 빈을 찾아서 사용하도록 변경되었다.

이 글은 인프런 김영한님의 Spring 강의를 바탕으로 개인적인 정리를 위해 작성한 글입니다.


회원 도메인 설계

회원 도메인 요구사항

  • 회원을 가입하고 조회할 수 있다.
  • 회원은 일반과 VIP 두 가지 등급이 있다.
  • 회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다. (미확정)

 

회원 도메인 협력 관계

 

회원 클래스 다이어그램

 

회원 객체 다이어그램

회원 서비스: MemberServiceImpl

구현 클래스가 하나밖에 없을 때는 Impl을 관례적으로 붙인다고 한다.

 

회원 도메인 개발

회원 엔티티

회원 등급

package hello.core.member;
public enum Grade {
 BASIC, VIP
}

 

회원 엔티티

package hello.core.member;

public class Member {
    private Long id;
    private String name;
    private Grade grade;

    public Member(Long id, String name, Grade grade) {
        this.id = id;
        this.name = name;
        this.grade = grade;
    }
    
    public Long getId() {
        return id;
    }
    public void setId(Long id) {
        this.id = id;
    }
    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }
    public Grade getGrade() {
        return grade;
    }
    public void setGrade(Grade grade) {
        this.grade = grade;
    }
}

 

회원 저장소

회원 저장소 인터페이스

package hello.core.member;

public interface MemberRepository {
    void save(Member member);
    Member findById(Long memberId);
}

 

메모리 회원 저장소 구현체

package hello.core.member;

import java.util.HashMap;
import java.util.Map;

public class MemoryMemberRepository implements MemberRepository{
    private static Map<Long, Member> store = new HashMap<>();
    @Override
    public void save(Member member) {
        store.put(member.getId(), member);
    }
    @Override
    public Member findById(Long memberId) {
        return store.get(memberId);
    }
}
HashMap 은 동시성 이슈가 발생할 수 있다. 이런 경우 ConcurrentHashMap 을 사용해야 한다.

 

회원 서비스

회원 서비스 인터페이스

package hello.core.member;

public interface MemberService {
    void join(Member member);
    Member findMember(long memberId);
}

 

회원 서비스 구현체

package hello.core.member;

public class MemberServiceImpl implements MemberService{
    private final MemberRepository memberRepository = new MemoryMemberRepository();
    @Override
    public void join(Member member) {
        memberRepository.save(member);
    }
    @Override
    public Member findMember(long memberId) {
        return memberRepository.findById(memberId);
    }
}

 

회원 도메인 실행과 테스트

회원 가입 main

package hello.core;

import hello.core.member.Grade;
import hello.core.member.Member;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;

public class MemberApp {
    public static void main(String[] args) {
        MemberService memberService = new MemberServiceImpl();
        Member member = new Member(1L, "memberA", Grade.VIP);
        memberService.join(member);

        Member findMember = memberService.findMember(1L);
        System.out.println("new member = " + member.getName());
        System.out.println("find member = " + findMember.getName());
    }
}

 

회원 가입 테스트

package hello.core.member;

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

public class MemberServiceTest {
    MemberService memberService = new MemberServiceImpl();

    @Test
    void join(){
        //given
        Member member = new Member(1L, "memberA", Grade.VIP);
        //when
        memberService.join(member);
        Member findeMember = memberService.findMember(1L);
        //then
        Assertions.assertThat(member).isEqualTo(findeMember);
    }
}

 

회원 도메인 설계의 문제점

  • OCP, DIP 를 잘 지키고 있지 않음.
  • 의존관계가 인터페이스 뿐만 아니라 구현까지 모두 의존하는 문제점이 있음

 

주문과 할인 도메인 설계

주문과 할인 정책

  • 회원은 상품을 주문할 수 있다.
  • 회원 등급에 따라 할인 정책을 적용할 수 있다.
  • 할인 정책은 모든 VIP는 1000원을 할인해주는 고정 금액 할인을 적용해달라. (나중에 변경 될 수 있다.)
  • 할인 정책은 변경 가능성이 높다. 회사의 기본 할인 정책을 아직 정하지 못했고, 오픈 직전까지 고민을 미루
    고 싶다. 최악의 경우 할인을 적용하지 않을 수 도 있다. (미확정)

 

주문 도메인 협력, 역할, 책임

  1. 주문 생성: 클라이언트는 주문 서비스에 주문 생성을 요청한다.
  2. 회원 조회: 할인을 위해서는 회원 등급이 필요하다. 그래서 주문 서비스는 회원 저장소에서 회원을 조회한다.
  3. 할인 적용: 주문 서비스는 회원 등급에 따른 할인 여부를 할인 정책에 위임한다.
  4. 주문 결과 반환: 주문 서비스는 할인 결과를 포함한 주문 결과를 반환한다.

 

주문 도메인 전체

역할과 구현을 분리해서 자유롭게 구현 객체를 조립할 수 있게 설계했다. 덕분에 회원 저장소는 물론이고, 할인 정책도 유연하게 변경할 수 있다.

 

주문 도메인 클래스 다이어그램

 

주문 도메인 객체 다이어그램1

회원을 메모리에서 조회하고, 정액 할인 정책(고정 금액)을 지원해도 주문 서비스를 변경하지 않아도 된다. 역할들의 협력 관계를 그대로 재사용 할 수 있다.

 

주문 도메인 객체 다이어그램2

회원을 메모리가 아닌 실제 DB에서 조회하고, 정률 할인 정책(주문 금액에 따라 % 할인)을 지원해도 주문 서비스를 변 경하지 않아도 된다. 협력 관계를 그대로 재사용 할 수 있다.

 

주문 할인 도메인 개발

할인 정책

할인 정책 인터페이스

package hello.core.discount;

import hello.core.member.Member;

public interface DiscountPolicy {
    //@return 리턴은 할인 대상 금액
    int discount(Member member, int price);
}

 

정액 할인 정책 구현체

package hello.core.discount;

import hello.core.member.Grade;
import hello.core.member.Member;

public class FixDiscountPolicy implements DiscountPolicy{

    private  int discountFixAmount = 1000; //천원 할인
    @Override
    public int discount(Member member, int price) {
        if(member.getGrade() == Grade.VIP){
            return  discountFixAmount;
        } else {
            return 0;
        }
    }
}
VIP면 1000원 할인, 아니면 할인 없음

 

주문

 

주문 엔티티

package hello.core.order;

public class Order {
    private long memberId;
    private String itemName;
    private int itemPrice;
    private int discountPrice;

    public Order(long memberId, String itemName, int itemPrice, int discountPrice){
        this.memberId = memberId;
        this.itemName = itemName;
        this.itemPrice = itemPrice;
        this.discountPrice = discountPrice;
    }

    public long getMemberId() {
        return memberId;
    }

    public void setMemberId(long memberId) {
        this.memberId = memberId;
    }

    public String getItemName() {
        return itemName;
    }

    public void setItemName(String itemName) {
        this.itemName = itemName;
    }

    public int getItemPrice() {
        return itemPrice;
    }

    public void setItemPrice(int itemPrice) {
        this.itemPrice = itemPrice;
    }

    public int getDiscountPrice() {
        return discountPrice;
    }

    public void setDiscountPrice(int discountPrice) {
        this.discountPrice = discountPrice;
    }

    @Override
    public String toString() {
        return "Order{" +
                "memberId=" + memberId +
                ", itemName='" + itemName + '\'' +
                ", itemPrice=" + itemPrice +
                ", discountPrice=" + discountPrice +
                '}';
    }
}

 

주문 서비스 인터페이스

package hello.core.order;

public interface OrderService {
    Order createOrder(long memberId, String itemName, int itemPrice);
}

 

주문 서비스 구현체

package hello.core.order;

import hello.core.discount.DiscountPolicy;
import hello.core.discount.FixDiscountPolicy;
import hello.core.member.Member;
import hello.core.member.MemberRepository;
import hello.core.member.MemoryMemberRepository;

public class OrderServiceImpl implements OrderService{
    private final MemberRepository memberRepository = new MemoryMemberRepository();
    private  final DiscountPolicy discountPolicy = new FixDiscountPolicy();
    @Override
    public Order createOrder(long memberId, String itemName, int itemPrice) {
        Member member = memberRepository.findById(memberId);
        int discountPrice = discountPolicy.discount(member, itemPrice);

        return new Order(memberId, itemName, itemPrice, discountPrice);
    }
}
주문 생성 요청이 오면, 회원 정보를 조회하고, 할인 정책을 적용한 다음 주문 객체를 생성해서 반환한다. 메모리 회원 리포지토리와, 고정 금액 할인 정책을 구현체로 생성한다.

 

주문과 할인 도메인 실행과 테스트

주문과 할인 정책 실행

package hello.core;

import hello.core.member.Grade;
import hello.core.member.Member;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import hello.core.order.Order;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;

public class OrderApp {
    public static void main(String[] args) {
        MemberService memberService = new MemberServiceImpl();
        OrderService orderService = new OrderServiceImpl();

        long memberId = 1L;
        Member member = new Member(memberId, "memberA", Grade.VIP);
        memberService.join(member);

        Order order = orderService.createOrder(memberId, "itemA", 10000);
        System.out.println("order = " + order);
    }
}

 

주문과 할인 정책 테스트

package hello.core.order;

import hello.core.member.Grade;
import hello.core.member.Member;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;

public class OrderServiceTest {
    MemberService memberService = new MemberServiceImpl();
    OrderService orderService = new OrderServiceImpl();

    @Test
    void createOrder(){
        long memberId = 1L;
        Member member = new Member(memberId, "memberA", Grade.VIP);
        memberService.join(member);

        Order order = orderService.createOrder(memberId, "itemA", 10000);
        Assertions.assertThat(order.getDiscountPrice()).isEqualTo(1000);
    }
}

이 글은 인프런 김영한님의 Spring 강의를 바탕으로 개인적인 정리를 위해 작성한 글입니다.


자바 진영의 표준 기술이었던 Enterprise Java Beans (EJB)는 복잡하고 어려우며 의존적이고 느렸음.

스프링

2002년 로드 존슨 책 출간

  • EJB의 문제점 지적
  • 지금의 스프링 핵심 개념과 기반 코드가 들어있음
  • BeanFactory, ApplicationContext, POJO, 제어 역전, 의존관계 주입
  • 단순함의 승리 현재 사실상 표준 기술

EJB 엔티티빈 기술을 대체 ->  하이버네이트 -> JPA

JPA는 인터페이스이다. 따라서 구현체가 필요한데, 대표적인 구현체는 하이버네이트, EclipseLink 등이 있다.

 

스프링 생태계

스프링은 여러 가지 기술들의 모음.

  • 스프링 프레임워크: 스프링의 핵심
  • 스프링 부트: 여러 스프링 기술들을 편리하게 사용하도록 도와줌
  • 스프링 데이터: CRUD를 편리하게 사용할수 있도록 도와주는 기술
  • 스프링 세션: 세션 기능을 편리하게 사용할 수 있도록 도와줌
  • 스프링 시큐리티: 보안과 관련
  • 스프링 Rest Docs: API 문서를 편리하게 해줌
  • 스프링 배치: 배치 처리에 특화된 기술
  • 스프링 클라우드: 클라우드에 특화된 기술

 

스프링 프레임워크 

  • 핵심 기술: 스프링 DI 컨테이너, AOP, 이벤트
  • 웹 기술: 스프링 MVC, 스프링 WebFlux
  • 데이터 접근 기술: 트랜잭션, JDBC, ORM 지원, XML 지원
  • 기술 통합: 캐시, 이메일, 원격접근, 스케줄링
  • 테스트: 스프링 기반 테스트 지원
  • 언어: 코틀린, 그루비

최근에는 스프링 부트를 통해서 스프링 프레임워크의 기술들을 편리하게 사용

 

스프링 부트

  • 스프링을 편리하게 사용할 수 있도록 지원, 최근에는 기본으로 사용
  • 단독으로 실행할 수 있는 스프링 애플리케이션을 쉽게 생성
  • Tomcat 같은 웹 서버를 내장해서 별도의 웹 서버를 설치하지 않아도 됨
  • 손쉬운 빌드 구성을 위한 starter 종속성 제공
  • 스프링과 3rd party(외부) 라이브러리 자동 구성
  • 메트릭, 상태 확인, 외부 구성 같은 프로덕션 준비 기능 제공
  • 관례에 의한 간결한 설정

 

스프링의 핵심

  • 스프링은 자바 언어 기반의 프레임워크
  • 자바 언어의 가장 큰 특징 - 객체 지향 언어
  • 스프링은 객체 지향 언어가 가진 강력한 특징을 살려내는 프레임워크
  • 스프링은 좋은 객체 지향 애플리케이션을 개발할 수 있게 도와주는 프레임워크

 

객체지향 프로그래밍

객체 지향 특징

  • 추상화 (Abstraction) : 공통의 속성이나 기능을 묶어 이름을 붙이는 것
    Ex. 객체들을 묶는 클래스를 정의
  • 캡슐화 (Encapsulation) : 하나의 목적에 따라 데이터의 구조와 데이터를 다루는 방법들을 결합시켜 묶는 것
    Ex. 변수와 함수를 하나로 묶는 것 (외부에서는 오로지 함수를 통해서만 접근)
  • 상속 (Inheritance) : 상위 개념의 특징을 하위 개념이 물려받는 것
    Ex. 부모 클래스에서 특정 기능을 추가하고 싶다면 상속하여 특정 기능을 추가한 자식 클래스를 생성
  • 다형성 (Polymorphism) : 하나의 객체가 여러 가지 형태를 가질 수 있는 것
    Ex. 오버라이딩, 오버로딩

객체 지향 프로그래밍은 컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러개의 독립된 단위, 즉 "객체"들의 모임으로 파악하고자 하는 것이다.

각각의 객체는 메시지를 주고받고, 데이터를 처리할 수 있다. (협력)

객체 지향 프로그래밍은 프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용된다.

 

다형성이란(사용자와 인터페이스, 구현체)

역할과 구현 구분하는 시각이다.

자동차 역할을 K3, 아반떼, 테슬라 세 개의 다른 자동차가 구현을 함.

운전자는 K3를 타다 아반떼로 자동차를 바꿔도 운전을 할 수 있다.

왜냐면 자동차 역할에 대한 구현만 바뀌었을뿐, 자동차가 바뀌어도 운전자에게 영향을 주지 않기 때문.

역할과 구현을 분리했기 때문에 운전자는 자동차 인터페이스 (역할)만 알 뿐, 그 내부 구조 (구현)는 몰라도 된다.

클라이언트에 영향을 주지 않고 새로운 기능을 제공하며, 무한히 확장할 수 있다.

역할 & 구현으로 세상을 구분했기 때문에새로운 자동차가 나와도 클라이언트는 배우지 않아도 된다.

 

로미오 역할을 하는 사람은 장동건이어도, 원빈이어도 된다. (구현을 대체 가능)

로미오 역할을 하는 사람은 줄리엣 역할을 누가 하는지 몰라도 된다. (역할만 알면 됨)

줄리엣 역할의 구현이 바뀐다 한들 로미오 역할에 영향을 주지 않음. 다른 대상으로 대체가 가능

 

역할과 구현을 분리

역할과 구현으로 구분하면 세상이 단순해지고, 유연해지며 변경도 편리해진다.

장점

  • 클라이언트는 대상의 역할(인터페이스)만 알면 된다.
  • 클라이언트는 구현 대상의 내부 구조를 몰라도 된다.
  • 클라이언트는 구현 대상의 내부 구조가 변경 되어도 영향을 받지 않는다.
  • 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다.

 

자바 언어

  • 자바 언어의 다형성을 활용
    역할 = 인터페이스
    구현 = 인터페이스를 구현한 클래스, 구현 객체
  • 객체를 설계할 때 역할과 구현을 명확히 분리
  • 객체 설계시 역할(인터페이스)을 먼저 부여, 이후 그 역할을 수행하는 구현 객체를 만든다.

 

객체의 협력 관계

혼자 있는 객체는 없다.

  • 클라이언트: 요청, 서버: 응답
  • 수많은 객체 클라이언트와 객체 서버는 서로 협력 관계를 가진다.

 

자바 언어의 다형성

오버라이딩을 예로들면

java
public class MemberService {
		private MemberRepository memberRepository = new MemoryMemberRepository();
//		private MemberRepository memberRepository = new JdbcMemberRepository();
}

오버라이딩 된 메서드가 실행된다.

이는 다형성으로 인터페이스를 구현한 객체를 실행 시점에 유연하게 변경할 수 있다.

MemberService(클라이언트)는 MemberRepository에 의존적이다.

 

 

다형성의 본질

  • 인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경할 수 있다.
  • 다형성의 본질을 이해하려면 협력이라는 객체 사이의 관계에서 시작해야 한다.

클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있다.

역할과 구현을 분리

  • 유연하고, 변경이 용이 → 확장 가능한 설계
  • 클라이언트에 영향을 주지 않는 변경 가능
  • 인터페이스를 안정적으로 잘 설계하는 것이 중요
  • 역할(인터페이스) 자체가 변하면, 클라이언트, 서버 모두에 큰 변경이 발생한다.

 

스프링과 객체 지향

  • 다형성이 가장 중요
  • 스프링은 다형성을 극대화해서 이용할 수 있게 도와준다.
  • 스프링의 제어 역전(IoC), 의존관계 주입(DI)은 다형성을 활용해 역할과 구현을 편리하게 다룰 수 있도록 지원한다.
  • 스프링을 사용하면 공연 무대의 배우를 선택하듯이! 구현을 편리하게 변경할 수 있다.

 

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

클린코드 저자 로버트 마틴이 정리한 좋은 객체 지향 설계의 5가지 원칙

  • SRP: 단일 책임 원칙 (Single Reponsibility Principle)
  • OCP: 개방-폐쇄 원칙 (Open-Closed Principle)
  • LSP: 리스코프 치환 원칙 (Liskov Substitution Principle)
  • ISP: 인터페이스 분리 원칙 (Interface Segregation Principle)
  • DIP: 의존관계 역전 원칙 (Dependency Inversion Principle)

 

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

  • 한 클래스는 하나의 책임만 가져야 한다.
  • 하나의 책임이라는 것은 모호하다.
  • 클 수 있고, 작을 수 있다. (문맥과 상황에 따라 다름)
  • 중요한 기준은 변경이다. 변경이 있을 때 파급효과가 적으면 단일 책임 원칙을 잘 따른 것.
    (UI 변경, 객체의 생성과 사용을 분리 등)

 

OCP: 개방-폐쇄 원칙 (Open-Closed Principle)

  • 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
  • 코드의 변경 없이 기능을 확장할 수 있어야 한다. → 다형성
  • 인터페이스를 구현한 새로운 클래스를 만들어 새로운 기능을 구현
  • 역할과 구현의 분리

 

문제점

public class MemberService {
private MemberRepository memberRepository = new MemoryMemberRepository();
// private MemberRepository memberRepository = new JdbcMemberRepository();
}
  • MemberService 클라이언트가 구현 클래스를 직접 선택
  • 구현 객체를 변경하려면 클라이언트 코드를 변경해야 한다.
  • 다형성을 사용했지만 OCP 원칙을 지킬 수 없다. (클라이언트의(MemberSerivce) 기존 코드 변경)
  • 객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다. (Spring의 DI / IoC 필요)

 

LSP: 리스코프 치환 원칙 (Liskov Substitution Principle)

  • 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
  • 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다.
  • 인터페이스를 구현한 구현체를 믿고 사용하려면, 이 원칙이 필요하다.
  • 단순히 컴파일에 성공하는 것을 넘어서는 이야기
    Ex. 자동차 인터페이스의 엑셀은 앞으로 가라는 기능, 뒤로 가게 구현하면 LSP를 위반한 것.

 

ISP: 인터페이스 분리 원칙 (Interface Segregation Principle)

  • 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
  • 자동차 인터페이스 → 운전 인터페이스, 정비 인터페이스로 분리
  • 사용자 클라이언트 → 운전자 클라이언트, 정비사 클라이언트로 분리
  • 분리하면 정비 인터페이스가 변해도 운전자 클라이언트에 영향을 주지 않음.
  • 인터페이스가 명확해지고, 대체 가능성이 높아진다.

 

DIP: 의존관계 역전 원칙 (Dependency Inversion Principle)

  • 추상화에 의존해야지, 구체화에 의존하면 안 된다.
  • 클라이언트 코드는 구현 클래스가 아닌, 인터페이스에 의존해야 한다.
  • 구현이 아닌 역할(Role)에 의존하게 해야 한다.
  • 클라이언트가 인터페이스에 의존해야 유연하게 구현체를 변경할 수 있다.
    구현체에 의존하게 되면 변경이 아주 어려워진다.

 

문제점

public class MemberService {
private MemberRepository memberRepository = new MemoryMemberRepository();
// private MemberRepository memberRepository = new JdbcMemberRepository();
}

MemberRepository memberRepository = new MemoryMemberRepository();
→ MemberService 클라이언트가 구현 클래스를 직접 선택 (구현에 의존)

정리
객체 지향의 핵심은 다형성
다형성 만으로는 쉽게 부품을 갈아 끼우듯 개발할 수 없다.
다형성 만으로는 구현 객체를 변경할 때 클라이언트 코드도 함께 변경 된다.
다형성 만으로는 OCP, DIP를 지킬 수 없다.

 

객체 지향 설계와 스프링

  • 스프링은 다음 기술로 다형성 + OCP, DIP를 가능하게 지원
  • DI(Dependency Injection): 의존관계, 의존성 주입
  • DI 컨테이너 제공
  • 클라이언트 코드의 변경 없이 기능 확장 (쉽게 부품을 교체하듯이 개발)

순수 자바로 OCP, DIP 원칙을 지키며 개발을 하면, 결국 스프링의 DI 컨테이너를 사용하게 된다.

최종 정리
모든 설계에 역할과 구현을 분리하자.
애플리케이션 설계도 공연을 설계하듯이 배역만 만들어두고, 배우는 언제든 유연하게 변경할 수 있도록 만드는 것이 좋은 객체 지향 설계다.
이상적으로는 모든 설계에 인터페이스를 부여하자.

이 글은 인프런 김영한님의 Spring 강의를 바탕으로 개인적인 정리를 위해 작성한 글입니다.


AOP가 필요한 상황

몇개의 메서드에 실행시간을 체크해보고싶은 상황이라고 한다면 해당 메서드들의 시작과 끝에 시간을 측정하고 출력하는 코드를 붙여야할 것이다.

다행히 그게 몇개 밖에 되지않는다면 괜찮겠지만 만약 몇십개, 몇백개라면 노가다 작업을 해야할 것이다.

예를 들어, AOP를 적용하지 않고, 각 메서드마다 실행시간을 측정을 해야한다면 아래와 같은 문제점을 만나게 된다.

  • 회원가입, 회원 조회에 시간을 측정하는 기능은 핵심 관심 사항이 아니다.
  • 시간을 측정하는 로직은 공통 관심 사항이다.
  • 시간을 측정하는 로직과 핵심 비즈니스의 로직이 섞여서 유지보수가 어렵다.
  • 시간을 측정하는 로직을 별도의 공통 로직으로 만들기 매우 어렵다.

 

이때 필요한 기술이 바로 AOP이다.

AOP는 공통적인사항(시간측정)을 핵심관심사항과 아래와 같이 분리해준다.

 

AOP 적용 전

 

AOP 적용 후

 

 

AOP 적용

  • AOP: Aspect Oriented Programming
  • 공통 관심 사항(cross-cutting concern), 핵심 관심 사항(core concern) 분리

package hello.hellospring.aop;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.springframework.stereotype.Component;
@Component
@Aspect
public class TimeTraceAop { 
    @Around("execution(* hello.hellospring..*(..))") //적용 범위
    public Object execute(ProceedingJoinPoint joinPoint) throws Throwable {
        long start = System.currentTimeMillis();
        System.out.println("START: " + joinPoint.toString());
        try {
            return joinPoint.proceed();
        } finally {
            long finish = System.currentTimeMillis();
            long timeMs = finish - start;
            System.out.println("END: " + joinPoint.toString()+ " " + timeMs + "ms");
        }
    }
}

컴포넌트 스캔방식으로 스프링 빈으로 등록해주고 @Aspect라는 어노테이션을 붙여준다.

그리고 실행할 함수(execute 메서드)를 작성한다.

시간을 측정해야하기때문에 시작 시간을 측정해준 뒤 try문에서 JointPoint의 proceed 메서드를 실행해준다.

메서드가 끝난 후에 종료 시간을 측정한뒤 종료 시간에서 시작 시간의 차이를 구하여 경과시간을 출력해준다.

execute함수 위에 @Around 어노테이션을 붙여서 어디까지 이 시간측정을 적용할지 범위를 정해줄 수 있다.

여기서는 모든 메서드에 적용하도록 hello.hellospring 의 모든 하위 패키지를 적용시킨 것이다.

 

이로써 AOP를 적용시키기 전에 문제점을 아래와 같이 해결하였다.

  • 회원가입, 회원 조회등 핵심 관심사항과 시간을 측정하는 공통 관심 사항을 분리한다.
  • 시간을 측정하는 로직을 별도의 공통 로직으로 만들었다.
  • 핵심 관심 사항을 깔끔하게 유지할 수 있다.
  • 변경이 필요하면 이 로직만 변경하면 된다.
  • 원하는 적용 대상을 선택할 수 있다.

 

스프링의 AOP 동작 방식

AOP를 적용하기 전의 의존관계는 아래와 같다.

 

AOP 적용 후의 의존관계는 아래와 같다.

 

실제 스프링 빈들 앞에 proxy 빈을 만들어주고 스프링 컨테이너는 의존성 주입때 proxy빈을 넣어준다.

그러면 실제 빈을 실행할 때도 proxy빈이 수행되고 joinpoint가 각각의 메서드들이 실행될 때 개입해 시간체크를 해주는 방식이다.

여기서 joinpoint의 proceed()가 실행될 때 실제 프록시빈이 수행된다.

Mac

  • command + shift + t : 테스트 케이스 생성

  • option + enter : static import

  • command + option + v : 리턴 값을 받아줄 변수 자동 생성

  • command + n : 생성자, getter, setter 등 자동 생성

  • command + d : 라인 복제

  • ctrl + t : 리팩토링

  • option + command + m : 메서드 추출 리팩토링 (extract method)

  • command + shift + 왼쪽 or 오른쪽 : 프로젝트 탐색창 좌우 크기조절

  • command + option + b + 클릭: 인터페이스의 구현체 리스트를 보여줌

  • command + p : 생성자 목록

  • command + e : 최근 실행 파일

  • shift + shift : 전체 검색

  • command + d : 해당 라인을 아래에 복제

  • command + shift + : 코드 한 줄 혹은 선택 영역을 한 줄 위로 이동

  • command + shift +  : 코드 한 줄 혹은 선택 영역을 한 줄 아래로 이동

  • command + L : 행:열을 입력하여 원하는 코드 라인으로 이동

  • command + backspace : 라인 한줄 지우기

  • command + shift + r : file replace(패키지나 디렉토리 선택한 후)

  • option + command + m : 메서드 추출

  • option + command + n : 인라인으로 합치기

  • option + command + c : 상수 지정

  • ctrl + o : 메서드 오버라이드

  • command + option + 클릭 : 인터페이스를 구현한 구현체로 이동

  • Shift + F6 : 변수명 한번에 바꾸기

 

 

 

Windows

  • art + Enter : static import

  • Alt + Insert : 새로운 클래스나 패키지등을 만들 때 사용 또는 생성자, getter and setter을 만들 때 유용하다.

  • Shift+Ctrl+Alt+T : 리팩토링

  • Alt + Shift + m : 메소드 리팩토링의 Extract Method 생성

  • Ctrl + Alt + s : Files->settings 로 이동

  • Ctrl + b : 해당 코드의 구현부로 이동

  • Ctrl + Alt + v : 리턴값을 받을 변수 자동 생성(클래스타입을 예측하여 편하게 클래스와 이름을 자동 완성해주는 기능)

  • Ctrl + e : 최근 사용한 파일 목록을 조회한다.

  • Ctrl + Shift + enter : 줄의 끝에 ;를 자동으로 입력

  • psvm 입력 -> enter : public static void main(String[] args) {} 메인 메서드 자동 완성

  • iter 입력 -> enter : foreach문을 자동 완성

  • sout 입력 -> enter : System.out.println(); 자동 완성

  • Ctrl + E : 직전에 작업했던 파일 목록들을 확인

  • Ctrl + / : 바로 주석 처리

  • Ctrl+Alt+L : 코드 내의 라인들을 보기 좋게 정리

  • Ctrl + Alt + O : 사용하지 않는 Import 라인을 알아서 정리

  • Ctrl + D : 해당 라인을 아래에 복제

  • Shift + Enter : 현재 커서 위치가 가로로 어디에 있던, 바로 아래에 새로운 라인을 만들어주는 기능

  • Ctrl + Shfit + T : 테스트파일 생성을 위한 도구를 켜줌, 자동으로 폴더까지 만들어주며 메소드를 선택할 수 도 있음.

 

참고

https://howtolivelikehuman.tistory.com/202

https://seongho96.tistory.com/58

https://mangkyu.tistory.com/139

https://velog.io/@janeljs/IntelliJ-IDEA-useful-shortcuts

 

이 글은 인프런 김영한님의 Spring 강의를 바탕으로 개인적인 정리를 위해 작성한 글입니다.


H2 데이터베이스 설치

H2 데이터베이스는 개발이나 테스트 용도로 가볍고 편리한 DB, 웹 화면 제공한다.

https://www.h2database.com/html/main.html

위 사이트에서 H2 데이터베이스를 설치한다.

브라우저 창이 열리면서 다음과같은 화면이 출력된다.
JDBC URL : jdbc:h2:~/test (최초 한번 입력)를 입력한다.

~/test는 home에 있는 test파일을 의미한다. window에서 home은 사용자 폴더가 된다.
사용자명과 비밀번호는 건드리지 않고 [연결] 버튼을 누른다.

그러면 해당 폴더에 위와 같은 파일이 생성된다.

 

아래와같이 H2 Database에 연결이되며, 좌측 상단에 연결끊기 라는 툴팁이 뜨는 버튼을 클릭하면 접속이 종료되고 초기 페이지가 출력된다.
JDBC URL에 설정된 jdbc:h2:~/test 와 같이 파일로 직접 접근하게되면 애플리케이션과 WebConsle에 동시에 접근이 불가능할 수 있기 때문에 이후 부터는jdbc:h2:tcp://localhost/~/test 경로를 입력하여 접속하는걸 권장한다.
이는 여러군데서 동시에 접속이 가능하기 위해 파일에 직접 접근하는것이 아닌 소켓을 통해 접근하도록 설정하는것이다.

 

블록지정된 박스에 member 테이블을 생성하는 sql문을 입력한다.
id의 컬럼타입인 bitint는 자바에서 Long타입일 경우 지정해준다.
generated by default as identity는 id를 null값으로 insert하게될때 DataBase가 자동으로 null값을 채워준다.
Oracle의 Sequence 혹은 MySQL의 AutoIncrement와 같다고 이해하면 된다.

create table member
( id bigint generated by default as identity,
 name varchar(255),
 primary key (id)
);

 

SELECT * FROM member 쿼리를 날리면 아래와 같이 정상적으로 데이터베이스가 생성된 것을 확인할 수 있다.

 

순수 JDBC

먼저 build.gradle 파일의 dependencies에 jdbc, h2 데이터베이스 관련 라이브러리 추가한다.

implementation 'org.springframework.boot:spring-boot-starter-jdbc'
runtimeOnly 'com.h2database:h2'

그 다음으로는 DB에 정보를 넣으려면 접속 정보를 넣어야 하는데, src - resources - application.properties에 밑의 코드를 적는다.

spring.datasource.url = jdbc:h2:tcp://localhost/~/test
spring.datasource.driver-class-name = org.h2.Driver
spring.datasource.username=sa

datasource의 드라이버 종류와 DB접속 URL을 입력하는것이다.
이렇게 세팅하면 자동으로 Database에 접속한다.

이후 gradle을 reload한다.

 

 

JDBC API를 이용하여 DB 연결

DB에 연결해서 사용하려면 data source 가 필요하다.
그러므로 DataSource Type의 변수를 final로 선언하고, 생성자를 통해 의존성 주입을 받는다.
spring boot가 Data Source를 만들어놓기 때문에, spring을 통해 의존성 주입받을 수 있다.

public class JdbcMemberRepository implements MemberRepository{

    private final DataSource dataSource;
    
    public JdbcMemberRepository(DataSource dataSource) {
        this.dataSource = dataSource;
        //dataSource.getConnection();
    }
    ...

이후 dataSource.getConnection()을 통해 connection을 받을 수 있고, 여기에 sql문을 전달하여 DB에 정보를 넣고 뺄 수 있다

 

아래의 더보기를 클릭하면 전체 소스코드를 볼 수 있다.

더보기
package hello.hellospring.repository;
import hello.hellospring.domain.Member;
import org.springframework.jdbc.datasource.DataSourceUtils;
import javax.sql.DataSource;
import java.sql.*;
import java.util.ArrayList;
import java.util.List;
import java.util.Optional;public class JdbcMemberRepository implements MemberRepository {
    private final DataSource dataSource;
    public JdbcMemberRepository(DataSource dataSource) {
        this.dataSource = dataSource;
    }
    @Override
    public Member save(Member member) {
        String sql = "insert into member(name) values(?)";
        Connection conn = null;
        PreparedStatement pstmt = null;
        ResultSet rs = null;
        try {
            conn = getConnection();
            pstmt = conn.prepareStatement(sql, Statement.RETURN_GENERATED_KEYS);
            pstmt.setString(1, member.getName());
            pstmt.executeUpdate();
            rs = pstmt.getGeneratedKeys();
            if (rs.next()) {
                member.setId(rs.getLong(1));
            } else {
                throw new SQLException("id 조회 실패");
            }
            return member;
        } catch (Exception e) {
            throw new IllegalStateException(e);
        } finally {
            close(conn, pstmt, rs);
        }
    }
    @Override
    public Optional<Member> findById(Long id) {
        String sql = "select * from member where id = ?";
        Connection conn = null; PreparedStatement pstmt = null;
        ResultSet rs = null;
        try {
            conn = getConnection();
            pstmt = conn.prepareStatement(sql);
            pstmt.setLong(1, id);
            rs = pstmt.executeQuery();
            if(rs.next()) {
                Member member = new Member();
                member.setId(rs.getLong("id"));
                member.setName(rs.getString("name"));
                return Optional.of(member);
            } else {
                return Optional.empty();
            }
        } catch (Exception e) {
            throw new IllegalStateException(e);
        } finally {
            close(conn, pstmt, rs);
        }
    }
    @Override
    public List<Member> findAll() {
        String sql = "select * from member";
        Connection conn = null;
        PreparedStatement pstmt = null;
        ResultSet rs = null;
        try {
            conn = getConnection();
            pstmt = conn.prepareStatement(sql);
            rs = pstmt.executeQuery();
            List<Member> members = new ArrayList<>();
            while(rs.next()) { Member member = new Member();
                member.setId(rs.getLong("id"));
                member.setName(rs.getString("name"));
                members.add(member);
            }
            return members;
        } catch (Exception e) {
            throw new IllegalStateException(e);
        } finally {
            close(conn, pstmt, rs);
        }
    }
    @Override
    public Optional<Member> findByName(String name) {
        String sql = "select * from member where name = ?";
        Connection conn = null;
        PreparedStatement pstmt = null;
        ResultSet rs = null;
        try {
            conn = getConnection();
            pstmt = conn.prepareStatement(sql);
            pstmt.setString(1, name);
            rs = pstmt.executeQuery();
            if(rs.next()) {
                Member member = new Member();
                member.setId(rs.getLong("id"));
                member.setName(rs.getString("name"));
                return Optional.of(member);
            }
            return Optional.empty();
        } catch (Exception e) {
            throw new IllegalStateException(e);
        } finally {
            close(conn, pstmt, rs);
        }
    } private Connection getConnection() {
        return DataSourceUtils.getConnection(dataSource);
    }
    private void close(Connection conn, PreparedStatement pstmt, ResultSet rs) {
        try {
            if (rs != null) {
                rs.close();
            }
        } catch (SQLException e) {
            e.printStackTrace();
        }
        try {
            if (pstmt != null) {
                pstmt.close();
            }
        } catch (SQLException e) {
            e.printStackTrace();
        }
        try {
            if (conn != null) {
                close(conn);
            }
        } catch (SQLException e) {
            e.printStackTrace();
        }
    }
    private void close(Connection conn) throws SQLException {
        DataSourceUtils.releaseConnection(conn, dataSource);
    }
}

 

MemoryMemberRepository에서 JdbcMemberRepository로 변경

SpringConfig 클래스에서 MemoryMemberRepository에서 JdbcMemberRepository로 바꿔야 한다.

memberRepository()에서 return new MemoryMemberRepository()를  return new JdbcMemberRepository()로 바꾸면 된다

@Configuration
public class SpringConfig {

    @Bean
    public MemberService memberService() {
        return new MemberService(memberRepository());
    }

    @Bean
    public MemberRepository memberRepository(){
    	// Jdbc Repository로 변경
        return new JdbcMemberRepository();
    }
}

 

jdbc에 필요한 DataSource는 spring에서 제공을 하기 때문에 의존성 주입을 통해 받으면 된다.
@Configuration도 spring bean으로 관리가 되기 때문에 spring boot가 dataSource를 bean으로 생성하고 관리한다.

package hello.hellospring;
import hello.hellospring.repository.JdbcMemberRepository;
import hello.hellospring.repository.MemberRepository;
import hello.hellospring.service.MemberService;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import javax.sql.DataSource;
@Configuration
public class SpringConfig {
    private final DataSource dataSource;
    public SpringConfig(DataSource dataSource) {
        this.dataSource = dataSource;
    }
    @Bean
    public MemberService memberService() {
        return new MemberService(memberRepository());
    }
    @Bean
    public MemberRepository memberRepository() {
        // return new MemoryMemberRepository();
        return new JdbcMemberRepository(dataSource);
    }
}

 

여기까지 완료했다면, DB가 정상적으로 작동하는 것을 확인할 수 있다.

 

spring은 다형성을 사용할 수 있도록 spring container에서 dependency injection(DI)와 같은 것을 지원한다.
따라서 객체지향적인 설계가 가능하고 다형성을 활용할 수 있다.
이를 통해 DB의 구현체를 Memory에서 Jdbc로 변경할 때에 코드를 많이 수정하지 않고, SpringConfig에서만 수정하고 구현체를 변경할 수 있다.

이를 개방-폐쇄 원칙(OCP, Open-Closed Principle)이라고 한다.

따라서 스프링의 DI (Dependencies Injection)을 사용하면 기존 코드를 전혀 손대지 않고, 설정만으로 구현 클래스를
변경할 수 있다.

 

스프링 통합 테스트

@SpringBootTest
Spring Boot 애플리케이션을 테스트하기 위한 어노테이션이다.
이 어노테이션을 사용하면 Spring Boot 애플리케이션을 실제 실행환경과 유사하게 테스트할 수 있다.
보통 @SpringBootTest는 통합 테스트를 작성할 때 사용되며, 애플리케이션의 여러 구성 요소를 함께 테스트할 때 유용하다.
이 어노테이션을 사용하면 실제 애플리케이션과 동일한 컨텍스트를 로딩하고, 테스트를 실행할 수 있다.
데이터베이스와 연동해서 사용해야하기 때문에 통합 테스트를 이용한다.

@Transactional
테스트 케이스에 이 애노테이션이 있으면, 테스트 시작 전에 트랜잭션을 시작하고, 테스트 완료 후에 항상 롤백한다. 
이렇게 하면 DB에 데이터가 남지 않으므로 다음 테스트에 영향을 주지 않는다.
즉, 커밋을 하지 않고 롤백을 하므로써 테스트로 인한 쿼리로 데이터베이스에 영향을 받지 않는다.

package hello.hellospring.service;
import hello.hellospring.domain.Member;
import hello.hellospring.repository.MemberRepository;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.transaction.annotation.Transactional;
import static org.assertj.core.api.Assertions.assertThat;
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertThrows;
@SpringBootTest
@Transactional
class MemberServiceIntegrationTest {
    @Autowired MemberService memberService;
    @Autowired MemberRepository memberRepository;
    @Test
    public void 회원가입() throws Exception {
        //Given
        Member member = new Member();
        member.setName("hello");
        //When
        Long saveId = memberService.join(member); //Then
        Member findMember = memberRepository.findById(saveId).get();
        assertEquals(member.getName(), findMember.getName());
    }
    @Test
    public void 중복_회원_예외() throws Exception {
        //Given
        Member member1 = new Member();
        member1.setName("spring");
        Member member2 = new Member();
        member2.setName("spring");
        //When
        memberService.join(member1);
        IllegalStateException e = assertThrows(IllegalStateException.class,
                () -> memberService.join(member2));//예외가 발생해야 한다.
        assertThat(e.getMessage()).isEqualTo("이미 존재하는 회원입니다.");
    }
}

 

스프링 JDBC Template

  • 순수 Jdbc와 동일한 환경설정을 하면 된다.
  • 스프링 JdbcTemplate과 MyBatis 같은 라이브러리는 JDBC API에서 본 반복 코드를 대부분 제거해준다. 하지만 SQL은 직접 작성해야 한다.

스프링 JdbcTemplate 회원 리포지토리 생성

package hello.hellospring.repository;

import hello.hellospring.domain.Member;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.jdbc.core.RowMapper;
import org.springframework.jdbc.core.namedparam.MapSqlParameterSource;
import org.springframework.jdbc.core.simple.SimpleJdbcInsert;

import javax.sql.DataSource;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.Optional;

public class JdbcTemplateMemberRepository implements MemberRepository {

    private final JdbcTemplate jdbcTemplate;
    public JdbcTemplateMemberRepository(DataSource dataSource) {
        jdbcTemplate = new JdbcTemplate(dataSource);
    }
    @Override
    public Member save(Member member) {
        SimpleJdbcInsert jdbcInsert = new SimpleJdbcInsert(jdbcTemplate);
        jdbcInsert.withTableName("member").usingGeneratedKeyColumns("id");
        Map<String, Object> parameters = new HashMap<>();
        parameters.put("name", member.getName());
        Number key = jdbcInsert.executeAndReturnKey(new
                MapSqlParameterSource(parameters));
        member.setId(key.longValue());
        return member;
    }
    @Override
    public Optional<Member> findById(Long id) {
        List<Member> result = jdbcTemplate.query("select * from member where id = ?", memberRowMapper(), id);
        return result.stream().findAny();
    } @Override
    public List<Member> findAll() {
        return jdbcTemplate.query("select * from member", memberRowMapper());
    }
    @Override
    public Optional<Member> findByName(String name) {
        List<Member> result = jdbcTemplate.query("select * from member where  name = ?", memberRowMapper(), name);
        return result.stream().findAny();
    }
    private RowMapper<Member> memberRowMapper() {
        return (rs, rowNum) -> {
            Member member = new Member();
            member.setId(rs.getLong("id"));  // resultSet의 column이 id인 값을 long으로 가져와 id에 대입
            member.setName(rs.getString("name")); // resultSet의 column이 name인 값을 String으로 가져와 name에 대입
            return member;
        };
    }
}
  • getLong("컬럼명"): DB의 컬럼명에 해당하는 값을 Long으로 반환
  • getString("컬럼명"): DB의 컬럼명에 해당하는 값을 String으로 반환
  • ResultSet: 쿼리 결과를 담고 있는 객체

 

JdbcTemplate을 사용하도록 스프링 설정 변경

JdbcTemplate는 스프링이 자동으로 의존성 주입을 해주지 않기 때문에 따로 설정을 해주어야 한다. 

package hello.hellospring;
import hello.hellospring.repository.JdbcTemplateMemberRepository;
import hello.hellospring.repository.MemberRepository;
import hello.hellospring.service.MemberService;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import javax.sql.DataSource;
@Configuration
public class SpringConfig {
    private final DataSource dataSource; 
    public SpringConfig(DataSource dataSource) {
        this.dataSource = dataSource;
    }
    @Bean
    public MemberService memberService() {
        return new MemberService(memberRepository());
    }
    @Bean
    public MemberRepository memberRepository() {
        // return new MemoryMemberRepository();
        // return new JdbcMemberRepository(dataSource);
        return new JdbcTemplateMemberRepository(dataSource); //인터페이스 구현객체 변경
    }
}

 

 

JPA

  • JPA는 기존의 반복 코드는 물론이고, 기본적인 SQL도 JPA가 직접 만들어서 실행해준다.
  • JPA를 사용하면, SQL과 데이터 중심의 설계에서 객체 중심의 설계로 패러다임을 전환을 할 수 있다.
  • JPA를 사용하면 개발 생산성을 크게 높일 수 있다.

 

build.gradle 파일에 JPA, h2 데이터베이스 관련 라이브러리 추가

jdbc를 사용하지 않으므로 아래와 같이 주석 처리하거나 삭제하고  jpa 관련 라이브러리를 추가한다.

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-thymeleaf'
    implementation 'org.springframework.boot:spring-boot-starter-web'
    // implementation 'org.springframework.boot:spring-boot-starter-jdbc' 주석처리
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa' //JPA
    runtimeOnly 'com.h2database:h2' //H2 database
    testImplementation('org.springframework.boot:spring-boot-starter-test') {
    exclude group: 'org.junit.vintage', module: 'junit-vintage-engine'
    }
}

 

 

스프링 부트에 JPA 설정 추가

application.properties 아래 두 줄을 추가한다. 

//기존에 있었던 것
spring.datasource.url=jdbc:h2:tcp://localhost/~/test
spring.datasource.driver-class-name=org.h2.Driver
spring.datasource.username=sa

JPA에 의해 새로 추가된 것
spring.jpa.show-sql=true
spring.jpa.hibernate.ddl-auto=none
  • spring.jpa.show-sql=true : JPA가 생성한 SQL을 출력
  • spring.jpa.hibernate.ddl-auto=create : JPA가 엔티티 정보를 바탕으로 테이블을 자동으로 생성(none으로 설정시 해당 기능 꺼짐)

 

여기까지 완료했다면 gradle을 reloading 해줘야 한다.

 

JPA 엔티티 매핑

javax.persistence.entity가 import 되지 않는다면?

spring boot 3에는 Jakarta EE 9이 포함됨에 따라 javax 관련 패키지명이 javax에서 jakarta로 변경되었다.
따라서 jakarta로 사용해야 한다.
package hello.hellospring.domain;
import jakarta.persistence.Entity;
import jakarta.persistence.GeneratedValue;
import jakarta.persistence.GenerationType;
import jakarta.persistence.Id;
@Entity
public class Member {
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;
    public Long getId() {
        return id;
    }
    public void setId(Long id) {
        this.id = id;
    }
    public String getName() { return name;
    }
    public void setName(String name) {
        this.name = name;
    }
}
  • @Entity: JPA가 관리하는 엔티티
  • @Id: 기본키(PK) 매핑
  • @GeneratedValue(): 기본 키 자동 생성

 

JPA 회원 리포지토리

package hello.hellospring.repository;
import hello.hellospring.domain.Member;
import jakarta.persistence.EntityManager;
import java.util.List;
import java.util.Optional;
public class JpaMemberRepository implements MemberRepository {
    private final EntityManager em;
    public JpaMemberRepository(EntityManager em) {
        this.em = em;
    }
    public Member save(Member member) {
        em.persist(member);
        return member;
    }
    public Optional<Member> findById(Long id) {
        Member member = em.find(Member.class, id);
        return Optional.ofNullable(member);
    }
    public List<Member> findAll() {
        return em.createQuery("select m from Member m", Member.class)
                .getResultList();
    } public Optional<Member> findByName(String name) {
        List<Member> result = em.createQuery("select m from Member m where m.name = :name", Member.class)
                .setParameter("name", name)
                .getResultList();
        return result.stream().findAny();
    }
}
  • EntityManger: 엔티티를 관리하는 객체
  • EntityManger.persist(entity): 엔티티 저장
  • EntityManger.find(entityClass, primaryKey): 식별자로 조회
  • EntityManger.createQuery(JPQL, resultClass): JPQL 쿼리 결과 반환

 

서비스 계층에 트랜잭션 추가

스프링은 해당 클래스의 메서드를 실행할 때 트랜잭션을 시작하고 메서드가 정상 종료되면 트랜잭션을 커밋하고 만약 런타임 예외가 발생하면 롤백한다.
JPA를 통한 모든 데이터 변경은 트랜잭션 안에서 실행해야 한다.
MemberService 내 join()에서 데이터 삽입을 하는 DB 변경이 일어난다.

그러므로 MemberService 클래스나 join()메서드에 @Transactional을 붙여주어야 한다.

import org.springframework.transaction.annotation.Transactional
@Transactional
public class MemberService {}
  • @Transactional: 클래스나 메서드에 붙여줄 경우, 해당 범위 내 메서드가 트랜잭션이 되도록 보장

 

JPA를 사용하도록 스프링 설정 변경

JpaMemberRepository가 EntityManger를 의존하도록 생성자 의존성 주입을 한다.

package hello.hellospring;
import hello.hellospring.repository.*;
import hello.hellospring.service.MemberService;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import jakarta.persistence.EntityManager;
import javax.sql.DataSource;
@Configuration
public class SpringConfig {
    private final DataSource dataSource;
    private final EntityManager em;
    public SpringConfig(DataSource dataSource, EntityManager em) {
        this.dataSource = dataSource; this.em = em;
    }
    @Bean
    public MemberService memberService() {
        return new MemberService(memberRepository());
    }
    @Bean
    public MemberRepository memberRepository() {
        // return new MemoryMemberRepository();
        // return new JdbcMemberRepository(dataSource);
        // return new JdbcTemplateMemberRepository(dataSource);
        return new JpaMemberRepository(em);
    }
}

 

 

스프링 데이터 JPA

스프링 부트와 JPA만 사용해도 개발 생산성이 정말 많이 증가하고, 개발해야할 코드도 확연히 줄어든다.
여기에 스프링 데이터 JPA를 사용하면, 기존의 한계를 넘어 마치 마법처럼, 리포지토리에 구현 클래스 없이 인터페이스 만으로 개 발을 완료할 수 있다.
그리고 반복 개발해온 기본 CRUD 기능도 스프링 데이터 JPA가 모두 제공한다.
스프링 부트와 JPA라는 기반 위에, 스프링 데이터 JPA라는 환상적인 프레임워크를 더하면 개발이 정말 즐거워진다.
지금까지 조금이라도 단순하고 반복이라 생각했던 개발 코드들이 확연하게 줄어든다.
따라서 개발자는 핵심 비즈니스 로직을 개발하는데, 집중할 수 있다.
실무에서 관계형 데이터베이스를 사용한다면 스프링 데이터 JPA는 이제 선택이 아니라 필수이다.

JPA 설정

위의 JPA 설정을 그대로 사용한다.

 

스프링 데이터 JPA 회원 리포지토리

package hello.hellospring.repository;

import hello.hellospring.domain.Member;
import org.springframework.data.jpa.repository.JpaRepository;

import java.util.Optional;

// 1. JpaRepository를 extends 하는 인터페이스를 만들어 놓으면
// 2. 스프링 데이터 JPA가 인터페이스 구현체를 자동 생성하고 스프링 빈에 자동 등록함
public interface SpringDataJpaMemberRepository extends JpaRepository<Member, Long>, MemberRepository {

    Optional<Member> findByName(String name);
}

 

스프링 데이터 JPA 회원 리포지토리를 사용하도록 스프링 설정 변경

스프링 데이터 JPA가 SpringDataJpaMemberRepository를 스프링 빈으로 자동 등록해준다.

package hello.hellospring;

import hello.hellospring.repository.*;
import hello.hellospring.service.MemberService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class SpringConfig {
    private final MemberRepository memberRepository;

    // 스프링 데이터 JPA가 만든 인터페이스 구현체(memberRepository) 자동 주입
    @Autowired
    public SpringConfig(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }

    // memberService 스프링 빈 등록
    @Bean
    public MemberService memberService() {
        return new MemberService(memberRepository);   // memberService가 memberRepository 의존
    }

}

 

스프링 데이터 JPA 제공 기능

  • 인터페이스를 통한 기본적인 CRUD
  • findByName() , findByEmail() 처럼 메서드 이름 만으로 조회 기능 제공
  • 페이징 기능 자동 제공
 실무에서는 JPA와 스프링 데이터 JPA를 기본으로 사용하고, 복잡한 동적 쿼리는 Querydsl이라는 라이브
러리를 사용하면 된다.
Querydsl을 사용하면 쿼리도 자바 코드로 안전하게 작성할 수 있고, 동적 쿼리도 편리하게 작성할 수 있다.
이 조합으로 해결하기 어려운 쿼리는 JPA가 제공하는 네이티브 쿼리를 사용하거나, JdbcTemplate를 사용하면 된다.

static import는 클래스의 정적 멤버(메서드와 필드)를 클래스 이름 없이 직접 사용할 수 있도록 해준다.

이를 통해 코드의 가독성을 높일 수 있지만, 과도하게 사용할 경우 어느 클래스에서 메서드나 필드가 정의되었는지 혼란을 줄 수 있다.

 

예를들어, static import를 사용하지 않는 경우, 예를 들어 Math 클래스의 sqrt 메서드를 사용하려면 클래스 이름을 명시해야 한다.

double result = Math.sqrt(25);  // Math 클래스의 sqrt 메서드 사용

 

static import를 사용하면, 메서드를 클래스 이름 없이 직접 호출할 수 있다

import static java.lang.Math.sqrt;

...

double result = sqrt(25);  // Math.sqrt가 아닌 sqrt만으로 호출

 주의해야 할 것은 같은 클래스 내에 동일한 이름의 메소드가 있으면 클래스 자신의 메소드가 우선시 된다.

 

클래스내의 모든 정적 메소드를 import 하려면 다음과 같이 사용할 수 있다.

import static java.lang.Math.*;

하지만 일반적으로 import 에 * 를 사용하는 것은 권장 되지 않는다.

정적 메소드외에 정적 멤버 변수도 static import 의 대상이 된다.

import static java.lang.Math.PI;
System.out.println(PI);

static import는 특히 자주 사용하는 유틸리티 클래스나 상수 집합에 유용하다.

하지만, 너무 많은 정적 임포트는 코드의 명확성을 해칠 수 있으므로 적절히 사용하는 것이 중요하다.