[Spring] 컴포넌트 스캔과 의존관계 자동 주입

- 김영한 님의 '스프링 핵심원리 - 기본편'을 보고 정리한 글입니다 😊

스프링 핵심 원리 - 기본편 - 인프런 | 강의

---

- 지난 포스팅과 이어집니다 :D

[Spring] 스프링을 이용해 회원-주문 서비스 개발, 스프링 컨테이너와 싱글톤

 

| 컴포넌트 스캔

- 지난 포스팅까지 우리는 AppConfig라는 설정 정보 클래스를 이용해 스프링 빈의 의존관계를 주입하였다.

- 그러나, 빈의 개수가 많아질수록 이를 하나씩 관리하는 건 너무 귀찮은 일이다. 

- 설정 정보가 없어도 자동으로 스프링 빈을 등록할 수 없을까? 의존관계도 알아서 해줬으면 좋겠어.

    - 🚩컴포넌트 스캔, 그리고 @Autowired를 사용해보자!

 

[AutoAppconfig.java]

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

- @Bean이 하나도 없는 것을 볼 수 있다!

- @Component가 붙은 클래스를 스캔하여 스프링 빈으로 등록하게 된다.

    - 이때, 기존의 예제 코드인 AppConfig.java 역시 @Configuration이 붙어 있어 스캔 대상이 되기 때문에, 등록되지 않게 하기 위해서 excludeFilters를 사용하였다. (원래는 @Configuration이 붙은 클래스도 같이 스캔해주는 게 맞다)

    - 참고로, @Configuration 내부에 @Component가 있기 때문에 컴포넌트 스캔의 대상이 되는 것이다!

    - ⭐ 이후에 나올 다양한 어노테이션 (@Service, @Repository... 등등에도 @Component가 붙어 있다!)

 

- ⭐ 참고로! AutoAppConfig의 위치가 매우 중요하다. 

    - 이후 나오겠지만, 컴포넌트 스캔 시 대상 및 하위 패키지를 스캔하기 때문에, 본 예제에서는 ~Application.java가 존재하는 파일의 경로와 동일한 위치에 두었다. (src > main > java > group_name > directory_name > 여기!)

 

 

✔ 기존 코드 수정

- MemoryMemberRepository, RateDiscountPolicy에 @Component를 추가해준다.

 

[MemberServiceImpl.java]

@Component
public class MemberServiceImpl implements MemberService{
    private final MemberRepository memberRepository;

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

- 여기서는 의존관계 주입을 위해서 @Autowired를 추가적으로 붙여주었다.

- OrderServiceImpl에서도 동일한 방식으로 추가를 해주자.

 

✔ Test

public class AutoAppConfigTest {
    @Test
    public void basicScan() throws Exception {
        ApplicationContext ac = new AnnotationConfigApplicationContext(AutoAppConfig.class);
        MemberService bean = ac.getBean(MemberService.class);
        assertThat(bean).isInstanceOf(MemberService.class);
    }
}

- 테스트가 성공적으로 실행되는 것을 볼 수 있다.

 

 

✔ 동작 과정

1. @ComponentScan은 @Component가 붙은 모든 클래스를 스프링 빈으로 등록한다.

    - 기본적으로 클래스명을 스프링 빈 이름으로 사용한다. @Component("name")으로 직접 지정도 가능하다.

    - 이때, 클래스명의 가장 첫 글자는 소문자로 등록한다.

2. 생성자에 기입한 @Autowired를 통해, 스프링 컨테이너는 자동으로 해당 스프링 빈을 찾아서 주입한다.

    - 이때, 타입이 같은 빈을 주입한다. = ac.getBean(MemberRepository.class)

 

 

✔ 컴포넌트 스캔 시작 위치

- @ComponentScan(basePackages = "")로 지정이 가능하다.

    - 해당 패키지를 포함한, 하위 패키지를 모두 탐색한다.

    - {}로 묶어서 다중 지정도 가능하다.

- 혹은 basePackageClasses 옵션을 통해서 클래스의 패키지를 시작 위치로 둘 수 있다.

- 보통은 프로젝트 최상단에 두는 게 기본이다.

    - 참고로, @SpringBootApplication 내부에도 @ComponentScan이 들어있다.

 

---

| 컴포넌트 스캔 - 필터

- 컴포넌트 스캔 대상을 추가로 지정하거나, 제외할 대상을 지정해보자.

 

[MyIncludeComponent.java]

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface MyIncludeComponent {
}

- 컴포넌트 스캔 대상에 추가할 커스텀 애노테이션이다.

- @Target은 해당 어노테이션을 어디에 붙일지, @Retention은 어노테이션의 생명주기, @Documented는 javadoc을 통한 api 문저 생성 시 해당 어노테이션의 설명도 포함해주는 역할을 한다. 

    - 보통은 @Target 정도만 커스텀을 하고, 나머지는 대부분 그대로 설정한다고 봐도 된다.

 

[MyExcludeComponent.java]

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface MyExcludeComponent {
}

- 마찬가지로 제거 대상에 추가할 커스텀 애노테이션도 생성해주자.

 

[BeanA.java, BeanB.java]

@Component
@MyIncludeComponent
public class BeanA {
}

@Component
@MyExcludeComponent
public class BeanB {
}

- 그리고, 해당 애노테이션을 사용하는 클래스들도 각각 정의해주자. (@Component도 붙여주자)

 

 

✔ Test

public class ComponentFilterTest {
    @Test
    public void filterScan() throws Exception {
        ApplicationContext ac = new AnnotationConfigApplicationContext(ComponentFilterConfig.class);
        BeanA beanA = ac.getBean("beanA", BeanA.class);
        assertThat(beanA).isNotNull();

        assertThrows(NoSuchBeanDefinitionException.class,
                () -> ac.getBean("beanB", BeanB.class));
    }

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

    }
}

확인해보면, includeFilter에 적용된 @MyIncludeComponent를 가진 beanA의 경우 getBean으로 잘 찾아오지만, excludeFilter에 적용된 @MyExcludeComponent를 가진 beanB의 경우 예외가 터진다.

쉽게 생각해서, includeFilters에 선언된 class는 @Component 어노테이션을 붙여준 것과 동일한 역할을 하는 것!

 

🌱 여기서, static class로 ComponentFilterConfig를 선언한 이유

static으로 하지 않으면 inner class는 outer class에 종속되기 때문에, outer class의 객체가 생성되어야만 접근이 가능해진다.

반면에, static으로 선언하면 outer class의 객체 생성 유무와 상관없이 별개로 만들어지기 때문에 ComponentFilterConfig 클래스가 생성되고 빈으로 등록될 수 있게 된다. (선언하지 않으면 ComponentFilterTest 클래스가 먼저 만들어져야 하는데, 안 만들어졌으니 당연히 Bean을 못 찾아온다)

---

| 컴포넌트 스캔 - 동일한 빈 이름 등록

- 자동 빈 등록으로 등록된 2개의 빈이 동일한 이름을 가진다면?

    - ConflictingBeanDefinitionException 예외 발생

- 자동 빈 등록으로 등록한 빈과 수동 빈 등록으로 등록한 빈이 동일한 이름을 가진다면?

    - 이때는 수동 빈 등록이 우선이 되어, 수동 빈이 자동 빈을 오버라이딩해버린다.

    - 근데 최근에는 둘이 충돌나면 오류나도록 바꾸었다고 한다!

 

---

| 의존관계 주입 방법 

- 크게 4가지로 나눌 수 있다. (생성자, 수정자, 필드, 메서드)

 

✔ 생성자 주입

@Component
public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;
    
    @Autowired
    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy
            discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
}

- 생성자를 통해서 주입받는 방법. (가장 많이 사용된다)

- 생성자 호출 시점에 1번만 호출되는 것이 보장된다.

- 불변하며, 필수적인 의존관계에 사용한다.

- 각 필드를 final로 설정하였는데, 이는 값이 꼭 세팅되어야 함을 보장할 때 사용한다. (생성자 빼면 오류난다)

 

⭐ 스프링 빈의 생성자가 1개 있으면 @Autowired를 생략해도 자동 주입된다!

    - 보통 @RequiredArgConstructor와 함께 유용하게 쓰인다.

 

- 생성자 주입의 경우, OrderServiceImpl을 생성하는 시점에 생성자를 호출하며 빈 등록 + 의존관계 주입도 함께 일어난다.

 

 

✔ 수정자 주입 (setter)

@Component
public class OrderServiceImpl implements OrderService {
    private MemberRepository memberRepository;
    private DiscountPolicy discountPolicy;
    
    @Autowired
    public void setMemberRepository(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }
    @Autowired
    public void setDiscountPolicy(DiscountPolicy discountPolicy) {
        this.discountPolicy = discountPolicy;
    }
}

- setter를 통해 필드의 값을 변경하여 의존관계를 주입한다. (수정해야 하니까 final 제거)

- 선택적, 변경 가능성이 있는 의존관계에 사용한다.

- 선택적이라는 것은 @Autowired(required=false)로 두어서 주입할 대상이 없어도 동작하도록 할 수 있다는 의미이다.

    - 해당 옵션을 사용하면, 자동 주입할 대상이 없을 때 수정자 자체가 호출되지 않는다.

    - 혹은, 파라미터에 @Nullable을 붙이거나 Optional<>로 감싸주는 방법도 있다. 이 경우 null, Optional.empty로 들어간다.

- 생성자 주입과 달리, 객체 생성 시점이 아닌 그 생성 이후 의존관계가 주입된다.

 

 

✔ 필드 주입

@Component
public class OrderServiceImpl implements OrderService {

    @Autowired
    private MemberRepository memberRepository;
    @Autowired
    private DiscountPolicy discountPolicy;
}

- 필드에 그대로 주입하는 방법이다. 단순히 @Autowired만 붙여주면 된다.

- 외부에서 변경이 불가능하기 때문에 테스트가 어려우며, DI 프레임워크가 꼭 필요하다. 무조건 스프링에서 가져와야 한다.

- 웬만하면 사용하지 말고, @Configuration 같은 곳에서만 특수적으로 사용할 것. (혹은 테스트 코드에서)

 

 

✔ 일반 메서드 주입

@Component
public class OrderServiceImpl implements OrderService {
    private MemberRepository memberRepository;
    private DiscountPolicy discountPolicy;
    
    @Autowired
    public void init(MemberRepository memberRepository, DiscountPolicy
            discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
}

- 한 번에 여러 필드를 주입받을 수 있다.

- 일반적으로는 거의 사용하지 않는다.

 

🚩 정말 당연한 소리지만, 의존관계 자동 주입은 스프링 컨테이너에서 관리하는 스프링 빈이어야 한다.

일반 클래스에 @Autowired를 적용해도 당연히 아무 일도 일어나지 않는다!

---

| 무슨 주입 방법을 사용해야 할까? 

- 생성자 주입 방법을 권장한다. (내가 알기로는 스프링에서도 기본으로 권장하는 방법으로 알고 있다.)

 

✔ 불변성

의존관계가 주입된 이상, 종료 시점까지 변경할 일은 거의 존재하지 않는다.

오히려, 수정자 주입처럼 열어두게 되면 변경이 발생될 수 있기 때문에 상당히 위험하다. 

생성자 주입은 객체의 생성 시점에 딱 1번만 호출되기 때문에, 이후에 변경되는 일이 없다.

 

✔ 필수성 

수정자 주입의 경우, 스프링 사용 없이 단순히 자바 코드만으로 테스트를 진행할 때 

-> 자바 코드만으로 테스트 = 스프링 컨테이너를 거치지 않고 (ac.getBean) new를 통해 객체를 생성해서 진행하는 테스트.

@Autowired를 붙이면 의존관계가 없어도 오류가 발생하지 않는다. (컴파일 시점 오류 x)

 

그러나, 막상 실행하고 나면 NPE가 뜨는데, 당연히 의존관계가 없으니 실행 시점에 오류가 난다.

반면에, 생성자 주입의 경우 주입하지 않았을 때 컴파일 오류가 발생하기 때문에 확인하기 좋다.

또, 의존관계를 보통 파라미터로 넣어주기 때문에 코드를 까보지 않아도 뭐가 들어가는지 확인하기 좋다 ㅎㅎ

 

✔ final 키워드

생성자 주입의 경우, 객체 생성 시점에 호출되고 파라미터가 초기화되기 때문에 final 키워드가 사용 가능하지만, 

수정자 주입의 경우 객체 생성 이후 호출 및 초기화가 되기 때문에 final 키워드 사용이 불가능하다.

 

🚩 final 키워드는 상수화시키는 것이기 때문에, 재정의, 상속 등이 불가능해진다. 재정의가 안 되기 때문에 기본적으로 선언과 동시에 값을 할당하는 것이 일반적이다. 하지만, 생성자를 통해서 상수를 초기화하게 되면 선언과 동시에 할당을 하지 않아도 되는데, 이는 '생성자'라는 정의 자체가 객체를 생성할 때 무조건 진행하는 과정 중 하나이고, 상수값을 초기화한다면 해당 상수는 '반드시 값을 할당받음'을 보장하기 때문에 컴파일 오류가 나지 않는다. 

 

🚩 그러나, setter의 경우 객체가 생성된 이후에! .set()을 이용해서 접근하기 때문에 변수에 값을 할당하게 된다. 이때, 해당 객체에 상수가 존재하게 되면 상수는 생성이 되었지만 컴파일러 시점에서는 언제 초기화될지 알 수 없기 때문에 보통 final 키워드 사용을 막아놓는다.

 

아무튼, final을 사용하게 되면 상수 필드가 있을 때 개발자가 this.a = a; 이런 식으로 필드에 값을 주입하지 않을 때 컴파일 오류가 발생한다! 모든 오류 중에서 컴파일 시점 오류가 가장 좋다. 해결하기도 좋고...

 

추가적으로, 필드 주입의 경우 사용하지 않는 게 좋다. 

기본적으로 필드 주입은 스프링 컨테이너를 꼭 거치기 때문에 테스트 단계에서 개발자가 임의로 주입하는 것 자체가 불가능해진다.

---

| 더 짧게 최적화해보자! 

- 생성자 주입을 사용하는 건 좋지만, 아무래도 생성자가 꼭 있어야 한다는 점이 코드가 복잡해진다고 생각할 수 있을 것이다.

- 하지만...! 실제로 개발할 때는 생성자를 써줄 필요가 없다. Lombok을 사용하면 되기 때문에!

 

[OrderServiceImpl.java]

@Component
public class OrderServiceImpl implements OrderService{
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

    // @Autowired //생성자가 1개라면 @Autowired 생략 가능
    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
}

- 기존의 코드이다. @Autowired는 생략할 수 있지만, 여전히 생성자가 존재하는 게 못마땅하다.

- Lombok을 적용해보자!

 

[build.gradle] - dependency 추가

- 웬만하면 SpringBoot로 프로젝트 생성 시 lombok은 기본적으로 체크하는 게 좋다. 유용한 게 매우 많기 때문에...!

plugins {
    id 'org.springframework.boot' version '2.7.2'
    id 'io.spring.dependency-management' version '1.0.12.RELEASE'
    id 'java'
}

group = 'study'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '11'

//lombok 설정 추가 시작
configurations {
    compileOnly {
        extendsFrom annotationProcessor
    }
}
//lombok 설정 추가 끝

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter'

    //lombok 라이브러리 추가 시작
    compileOnly 'org.projectlombok:lombok'
    annotationProcessor 'org.projectlombok:lombok'
    testCompileOnly 'org.projectlombok:lombok'
    testAnnotationProcessor 'org.projectlombok:lombok'
    //lombok 라이브러리 추가 끝

    testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

tasks.named('test') {
    useJUnitPlatform()
}

- 추가하고 나서 코끼리 모양 클릭 or 오른쪽의 Gradle -> Reload 클릭해서 적용을 해줘야 한다.

- 이후, 설정에서 Annotation processors -> Enable annotation processing을 해주자.

 

그리고, 코드를 이렇게 수정해보자.

[OrderServiceImpl.java]

@Component
@RequiredArgsConstructor
public class OrderServiceImpl implements OrderService{
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;
}

- 코드가 매우 간결해졌다. 대부분 개발할 때 이렇게 사용하니까 꼭 기억해두도록 하자.

- 롬복을 사용하면 필드명을 기준으로 생성자 매개변수 이름을 가지기 때문에, 각 필드명으로 빈이 등록된다.

---

| 동일한 타입을 가진 빈 

- @Autowired는 기본적으로 타입으로 조회한다.

- 이전의 예제에서, 정액 할인 정책(Fix)과 정률 할인 정책(Rate)은 모두 DiscountPolicy 인터페이스를 구현한 구현체이다.

- 만약, 둘을 @Component를 통해 빈으로 등록하고, DiscountPolicy에 @Autowired를 붙이면 어떤 게 주입될까?

이 경우, NoUniqueBeanDefinitionException 예외가 발생한다.

 

 

✔ 해결 방법

- @Autowired 사용 시 필드명을 이용

@Autowired
private DiscountPolicy rateDiscountPolicy

다음과 같이 사용하게 되면, 1차적으로 DiscountPolicy 타입 매칭 -> rateDiscountPolicy 필드명 매칭을 진행한다.

(물론, DiscountPolicy가 중복되지 않는다면 필드명 매칭까지 가지 않는다. 2개 이상일 때만 진행)

 

 

- @Qualifier 사용하기

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

@Component
@Qualifier("fixDiscountPolicy")
public class FixDiscountPolicy implements DiscountPolicy {}

다음과 같이, 빈을 등록할 때 추가적인 구분자를 설정할 수 있다. (@Bean에도 함께 사용할 수 있다)

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

이후, 주입할 때 다음과 같이 등록한 구분자를 넣어주면 된다.

단, 주입할 때 @Qualifier를 계속 붙여줘야 한다는 점이 단점이다.

 

 

- @Primary 사용하기

@Component
@Primary
public class RateDiscountPolicy implements DiscountPolicy {}

@Component
public class FixDiscountPolicy implements DiscountPolicy {}

@Primary를 붙여주면 해당 빈이 우선권을 가지게 된다.

주입 시 DiscountPolicy에 별다른 처리를 하지 않아도 RateDiscountPolicy가 들어간다.

 

🚩 스프링은 항상 자동보다 수동이, 넓은 것보다 좁은 범위가 우선권을 가진다.

@Qualifier는 더 세세한 작업에 주로 사용하기 때문에, @Primary에 비해서 우선순위가 높다!

 

🚩 참고로, @RequriedArgsConstructor를 사용하면 애노테이션 정보는 포함시키지 않고 생성자를 만든다. 

즉, @Qualifier를 붙여도 해당 구분자가 적용되지 않는다는 것. 구분자를 지정하고 싶다면 필드명을 바꾸자. 

(적용할 수 있는 방법은 있기는 한데... config 정보를 수정해야 하는 거니까 웬만하면 필드 이름을 바꾸자!)

---

| 동일한 타입을 가진 빈 - 모두 사용하기

✔ Test

public class AutoAppConfigTest {
    @Test
    public void findAllBean() throws Exception {
        ApplicationContext ac
                = new AnnotationConfigApplicationContext(AutoAppConfig.class, DiscountService.class);
        DiscountService discountService = ac.getBean(DiscountService.class);
        Member member = new Member(1L, "userA", Grade.VIP);
        int discountPrice = discountService.discount(member, 10000, "fixDiscountPolicy");

        assertThat(discountService).isInstanceOf(DiscountService.class);
        assertThat(discountPrice).isEqualTo(1000);

    }

    static class DiscountService {
        private final Map<String, DiscountPolicy> policyMap;
        private final List<DiscountPolicy> policies;

        public DiscountService(Map<String, DiscountPolicy> policyMap, List<DiscountPolicy> policies) {
            this.policyMap = policyMap;
            this.policies = policies;
            System.out.println("policyMap = " + policyMap);
            System.out.println("policies = " + policies);
        }

        public int discount(Member member, int price, String discountCode) {
            DiscountPolicy discountPolicy = policyMap.get(discountCode);
            System.out.println("discountCode = " + discountCode);
            System.out.println("discountPolicy = " + discountPolicy);
            return discountPolicy.discount(member, price);
        }
    }
}

✔ 실행 결과

policyMap = {fixDiscountPolicy=study.springstudy.domain.service.discount.FixDiscountPolicy@46292372, rateDiscountPolicy=study.springstudy.domain.service.discount.RateDiscountPolicy@126be319}
policies = [study.springstudy.domain.service.discount.FixDiscountPolicy@46292372, study.springstudy.domain.service.discount.RateDiscountPolicy@126be319]

 

discountCode = fixDiscountPolicy
discountPolicy = study.springstudy.domain.service.discount.FixDiscountPolicy@46292372

 

- 여기서 Map을 활용한 것을 볼 수 있다. 이는 DiscountPolicy 타입을 가진 모든 빈이 주입된다.

    - 결과를 보면 policyMap에 DiscountPolicy 타입인 FixDiscountPolicy, RateDiscountPolicy가 주입되었다.

    - Map으로도 받을 수 있고, List로도 받을 수 있다. Map은 빈의 이름과 빈을, List는 빈을 리턴한다.

    - 여기서 조회되는 타입이 없으면 빈 컬렉션이 반환된다.

 

- 코드에서는 빈 이름을 넘겨서 policyMap에서 꺼내와 할인 정책을 결정한다.

    - fix를 넘겼기 때문에, 고정 금액인 1000원을 할인받아 discountPrice가 1000이 된다.

 

 

다음 포스팅에서는 빈의 생명주기, 빈 스코프에 대해서 다루도록 하겠다.