02

스프링 핵심 원리 - 기본편

Bean, Spring Container

• 2022/01/03 ~ 2022/01/07
• 2023/01/08 - PDF 복습
• 2024/06/05 - PDF 복습

DIP, OCP 위반

public class OrderServiceImpl implements OrderService {
    // private final DiscountPolicy discountPolicy = new FixDiscountPolicy();
    private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
}

• 역할과 구현을 분리
• 다형성도 활용하고, 인터페이스와 구현 객체를 분리
• DCP 위반: 추상(인터페이스) 뿐만 아니라 구체(구현) 클래스에도 의존
• OCP 위반: 기능을 활장해서 변경하면, 클라이언트 코드에 영향을 줌

DIP, OCP 위반 -> 해결

• 구현체(생성자)가 없으면 코드를 실행시킬 수 없음
• 이를 위해서 누군가가 클라이언트에 구현 객체를 대신 생성하고 주입해주어야 함
• 애플리케이션의 전체 동작 방식을 구성(config)하기 위해, 구현 객체를 생성하고 연결하는 책임을 가지는 별도의 설정 클래스 사용
  • 객체를 생성하고 구성하는 영역(역할)의 분리

public class OrderServiceImpl implements OrderService {
    
    private final DiscountPolicy discountPolicy;

    public OrderServiceImpl(DiscountPolicy discountPolicy) {
        this.discountPolicy = discountPolicy;
    }
}

@Configuration
public class AppConfig {

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

    @Bean
    public DiscountPolicy discountPolicy() {
        // return new FixDiscountPolicy();
        return new 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 코드만 보고 의존관계를 쉽게 판단할 수 있다.
• 정적인 의존관계는 애플리케이션을 실행하지 않아도 분석할 수 있다.

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

• 애플리케이션 실행 시점에 실제 생성된 객체 인스턴스의 참조가 연결된 의존 관계다.
• 애플리케이션 실행 시점(런타임)에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 클라이언트와 서버의 실제 의존관계가 연결 되는 것을 의존관계 주입이라 한다.
• 객체 인스턴스를 생성하고, 그 참조값을 전달해서 연결된다.
• 의존관계 주입을 사용하면 클라이언트 코드를 변경하지 않고, 클라이언트가 호출하는 대상의 타입 인스턴스를 변경할 수 있다.
• 의존관계 주입을 사용하면 정적인 클래스 의존관계를 변경하지 않고, 동적인 객체 인스턴스 의존관계를 쉽게 변경할 수 있다.

IoC 컨테이너, DI 컨테이너

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

스프링 컨테이너

• ApplicationContext 를 스프링 컨테이너라 한다.
• 기존에는 개발자가 AppConfig 를 사용해서 직접 객체를 생성하고 DI를 했지만, 이제부터는 스프링 컨테이너를 통해서 사용한다.
  • 강의에서 이 이전에 AppConfig 의 메서드를 직접 사용
• 스프링 컨테이너는 @Configuration 이 붙은 AppConfig 를 설정(구성) 정보로 사용한다. 여기서 @Bean 이라 적힌 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록한다. 이렇게 스프링 컨테이너에 등록된 객체를 스프링 빈이라 한다.
• 스프링 빈은 @Bean 이 붙은 메서드의 명을 스프링 빈의 이름으로 사용한다. ( memberService , orderService )
• 이전에는 개발자가 필요한 객체를 AppConfig 를 사용해서 직접 조회했지만, 이제부터는 스프링 컨테이너를 통해서 필요한 스프링 빈(객체)를 찾아야 한다. 스프링 빈은 applicationContext.getBean() 메서드를 사용해서 찾을 수 있다.
• 기존에는 개발자가 직접 자바코드로 모든 것을 했다면 이제부터는 스프링 컨테이너에 객체를 스프링 빈으로 등록하고, 스프링 컨테이너에서 스프링 빈을 찾아서 사용하도록 변경되었다.

BeanFactory

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

ApplicationContext

• BeanFactory 기능을 모두 상속받아서 제공
• 애플리케이션을 개발할 때는 빈을 관리하고 조회하는 기능은 물론, 수 많은 부가 기능 필요
  • 메시지소소스를 활용한 국제화 기능
    • 한국에서 들어오면 한국어로, 영어권에서 들어오면 영어로 출력
  • 환경변수
    • 로컬, 개발, 운영 등을 구분해서 처리
  • 애플리케이션 이벤트
    • 이벤트를 발생하고 구독하는 모델을 편리하게 지원
  • 편리한 리소스 조회
    • 파일, 클래스패스, 외부 등에서 리소스를 편리하게 조회

정리

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

BeanDefinition

• 스프링이 다양한 설정 형식을 지원하기 위한 추상화
  • 역할과 구현을 개념적으로 나눈 것
  • XML을 읽어서 BeanDefinition 생성
  • 자바 코드를 읽어서 BeanDefinition 생성
  • 스프링 컨테이너는 자바 코드인지, XML인지 몰라도 됨. 오직 BeanDefinition만 알면 됨
• BeanDefinition을 빈 설정 메타정보라 함
  • @Bean, <bean> 당 각각 하나씩 메타 정보 생성
• 스프링 컨테이너는 이 메타 정보를 기반으로 스프링 빈을 생성
• BeanDefinition을 직접 생성해서 스프링 컨테이너에 등록할 수도 있지만, 실무에서 직접 정의하거나 사용할 일은 거의 없음

싱글톤 패턴

싱글톤 패턴 문제점

• 싱글톤 패턴을 구현하는 코드 자체가 많이 들어감
• 의존관계상 클라이언트가 구체 클래스에 의존 -> DIP 위반
  • ex) MemberServiceImpl.getInstance()
• 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높음
• 테스트가 어려움
  • 설정이 다 된 객체가 박히므로 유연하게 테스트하기 어려움
• 내부 속성을 변경하거나 초기화 하기 어려움
• private 생성자로 자식 클래스를 만들기 어려움
• 결론적으로 유연성이 떨어짐
• 안티패턴으로 불리기도 함

싱글톤 컨테이너

• 스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤(1개만 생성)으로 관리
  • 싱글톤으로 관리되는 스프링 빈
  • 기본적으로 싱글톤이지만, 싱글톤 방식만 지원하는 것은 아님
• 스프링 컨테이너는 싱글턴 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리
• 스프링 컨테이너는 싱글톤 컨테이너 역할을 함
• 이렇게 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라 함
• 스프링 컨테이너의 이런 기능 덕분에 싱글턴 패턴의 모든 단점을 해결하면서 객체를 싱글톤으로 유지할 수 있음
  • 싱글톤 패턴을 위한 지저분한 코드가 들어가지 않아도 됨
  • DIP, OCP, 테스트, private 생성자로 부터 자유롭게 싱글톤을 사용할 수 있음

싱글톤 방식의 주의점

• 싱글톤 패턴이든, 스프링 같은 싱글톤 컨테이너를 사용하든, 객체를 하나만 생성해서 공유하는 싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체를 무상태(stateless)로 설계해야 함
  • 특정 클라이언트에 의존적인 필드가 있으면 안됨
  • 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안됨
  • 가급적 읽기만 가능해야 함
  • 필드 대신에 자바에서 공유되지 않는, 지역변수, 파라미터, ThreadLocal 등을 사용해야 함
• 스프링 빈의 필드에 공유 값을 설정하면 정말 큰 장애가 발생할 수 있다!!!

@Configuration

• 스프링 컨테이너는 싱글톤 레지스트리다. 따라서 스프링 빈이 싱글톤이 되도록 보장해주어야 한다. 그런데 스프링이 자바 코드까지 어떻게 하기는 어렵다. 그래서 스프링은 클래스의 바이트코드를 조작하는 라이브러리(CGLIB)를 사용한다.
• AppConfig@CGLIB -> AppConfig
• 빈 메서드들이 객체를 1개씩만 생성하도록
• @Bean이 붙은 메서드마다 이미 스프링 빈이 존재하면 존재하는 빈을 반환하고, 스프링 빈이 없으면 생성해서 스프링 빈으로 등록하고 반환하는 코드가 동적으로 만들어진다.

@Bean
public MemberRepository memberRepository() {
    if (memoryMemberRepository가 이미 스프링 컨테이너에 등록되어 있으면?) { 
        return 스프링 컨테이너에서 찾아서 반환;
    } else { //스프링 컨테이너에 없으면
        기존 로직을 호출해서 MemoryMemberRepository를 생성하고 스프링 컨테이너에 등록;
        return 반환;
    } 
}

컴포넌트 스캔

• @ComponentScan 을 설정 정보에 붙여주면 됨
• @Component 가 붙은 클래스 클래스 스캔해서 스프링 빈으로 등록
• @Autowired 를 통해 의존관계를 자동으로 주입

@ComponentScan

• @ComponentScan은 @Component가 붙은 모든 클래스를 스프링 빈으로 등록
• 이때 스프링 빈의 기본 이름은 클래스명을 사용하되 맨 앞 글자만 소문자를 사용
  • 빈 이름 기본 전략: MemberServiceImpl class -> memberServiceImpl
  • 빈 이름 직접 지정: @Component("memberService2")
    • 특별한 경우가 아니면 default 사용