의존관계 자동 주입

의존관계 자동 주입

1. 다양한 의존관계 주입 방법

1. 생성자 주입(constructor) ✔
2. 수정자 주입(setter)
3. 필드 주입
4. 일반 메서드 주입

1. 생성자 주입

생성자 호출 시점에 딱 1번만 호출되는 것 보장

✔ 불변, 필수 의존관계에 사용

// OrderServiceImpl.java

@Component
public class OrderServiceImpl implements OrderService{

//    final -> 반드시 값을 할당해줘야한다.(필수, 불변)
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;


    @Autowired // 생성자가 한 개만 있을 경우 생략해도 된다.
    public OrderServiceImpl(MemberRepository memberRepository, @MainDiscountPolicy  DiscountPolicy discountPolicy) {
//        System.out.println("memberRepository = " + memberRepository);
//        System.out.println("discountPolicy = " + discountPolicy);
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
    ...
}

생성자가 한 개만 있을 경우 `@Autowired 생략 가능

2. 수정자 주입(Setter 주입)

필드의 값읍 변경하는 수정자 메서드인 setter를 통해서 의존 관계 주입

선택, 변경 가능성이 있는 의존관계에 사용
자바빈 프로퍼티 규약의 수정자 메서드 사용

// OrderServiceImpl.java

@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랑 getter 메서드를 활용해 값을 읽거나 수정하는 규칙

3. 필드 주입

코드가 매우 간결하나 외부에서 변경이 불가능해 테스트하기 힘들다!

가급적 사용 자제!!

테스트코드나 스프링 설정 목적으로 하는 @Configuration같은 곳에서만 특별한 용도로 사용

// OrederServiceImpl.java

@Component
public class OrderServiceImpl implements OrderService {

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

4.일반 메서드 주입

한번에 여러 필드를 주입 받을 수 있으나 잘 사용하지는 않는다!

@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;
    }

}

2. 옵션처리

주입할 스프링 빈이 없어도 메서드를 동작하게 하고 싶을 경우 옵션 처리를 해야한다.

옵션 처리 방법

• @Autowired(required=false) : 자동 주입할 대상이 없으면 수정자 메서드 자체가 호출 안됨
• org.springframework.lang.@Nullable : 자동 주입할 대상이 없으면 null이 입력된다.
• Optional<> : 자동 주입할 대상이 없으면 Optional.empty 가 입력된다

// AutowiredTest.java

public class AutowiredTest {

    @Test
    void AutowiredOption() {
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(TestBean.class);
    }

    static class TestBean {

        // 스프링 빈에 등록되지 않은 대상 주입해보기 (Member)

        // 1. 의존 관계가 없으면 아예 호출이 안된다
        @Autowired(required = false)
        public void setNoBean1(Member noBean1) {
            System.out.println("noBean1 = " + noBean1);
        }

        // 2. null로 호출
        @Autowired
        public void setNoBean2(@Nullable Member noBean2) {
            System.out.println("noBean2 = " + noBean2);
        }

        // 3. Optional.empty 호출
        @Autowired
        public void setNoBean3(Optional<Member> noBean3) {
            System.out.println("noBean3 = " + noBean3);
        }
    }
}

// 테스트 결과

// 1. 은 호출이 안된다
noBean2 = null
noBean3 = Optional.empty

3. 생성자 주입을 선택하라

최근에는 생성자 주입이 권장된다

불변

✔ 대부분 의존 관계 주입은 한번 일어나면 애플리케이션 종료시점까지 변경할 일이 없으며 권장되지 않는다

수정자 주입을 사용하면 setter 메서드를 public으로 열여두어야 한다

• 누군가 실수로 변경 가능
• 변경 안되는 메서드를 열어두는 것은 지양

생성자 주입은 객체 생성 시에만 1번 호출되고 이후에 호출되지 않는다 -> 불변 설계

누락**

프레임워크 없이 순수한 자바 코드 단위로 실행 시(@Autowired 동작 x)

• 수정자 주입에서는 실행은 되나 NPE발생
• 생성자 메서드에서는 컴파일 오류 발생 -> 디버깅 용이

final

생성자 주입 사용 시 필드에 final 키워드를 사용할 수 있다 -> 생성자에서 값이 설정되지 않는 오류를 컴파일 시점에 잡아준다

예시 코드

@Component
public class OrderServiceImpl implements OrderService {

    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

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

컴파일 오류: java: variable discountPolicy might not have been initialized

※ 참고: 수정자 주입을 포함한 나머지 주입 방식은 모두 생성자 이후에 호출되므로, 필드에 final 키워드를 사용할 수 없다. 오직 생성자 주입 방식만 final 키워드를 사용 가능

4. 롬복과 최신 트렌드

매번 생성자 주입 코드 작성하기 번거롭다! -> 롬복 라이브러리 활용

롬복 라이브러리 설치 방법

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

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

repositories {
    mavenCentral()
}

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

dependencies {

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

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

}

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

1. Preferences(윈도우 File Settings) plugin lombok 검색 설치 실행 (재시작)
2. Preferences Annotation Processors 검색 Enable annotation processing 체크 (재시작)
3. 임의의 테스트 클래스를 만들고 @Getter, @Setter 확인

롬복을 활용한 의존관계 주입

기본 코드

// OrderServiceImpl.java

@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;
    }
}

롬복 적용

// OrderServiceImpl.java

@Component
@RequiredArgsConstructor // final이 붙은 인스턴스에 대한 생성자를 만들어 준다
public class OrderServiceImpl implements OrderService{

    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

    ...
}

✔ @RequiredArgsConstructor : final이 붙은 필드를 모아서 생성자를 자동으로 만들어준다

최근에는 생성자를 1개 두고 @Autowired를 생략하는 방법을 주로 사용하면서, Lombok라이브러리의 @RequiredArgsConstructor를 함께 사용한다

5. 조회 빈이 2개 이상일 때

@Autowired는 타입으로 조회한다 (ac.getBean(DiscountPolicy.class)와 유사) -> 같은 타입의 빈이 2개 이상이면 문제 발생!

예시

// FixDiscountPolicy.java

@Component
public class FixDiscountPolicy implements DiscountPolicy {}

// RateDiscountPolicy.java

@Component
public class RateDiscountPolicy implements DiscountPolicy {}

// 의존관게 자동 주입 실행

@Autowired
private DiscountPolicy discountPolicy

NoUniqueBeanDefinitionException: No qualifying bean of type 
'hello.core.discount.DiscountPolicy' available: 
expected single matching bean but found 2: fixDiscountPolicy,rateDiscountPolicy

NoUniqueBeanDefinitionException 오류 발생

그렇다고 하위 타입으로 지정하면 DIP 위배 및 유연성 감소! 그리고 하위 타입도 같으면 문제 발생 가능

그렇다면...?

6. @Autowired 필드 명, @Qualifier, @Primary

조회 대상 빈이 2개 이상일 때 해결 방법

1. @Autowired 필드 명 매칭
2. @Qualifier -> @Qualifier끼리 매칭 -> 빈 이름 매칭
3. @Primary 사용

1. @Autowired 필드 명 매칭

✔ @Autowired 는 타입 매칭을 시도하고, 이때 여러 빈이 있으면 필드 이름, 파라미터 이름으로 빈 이름을 추가 매칭한다.

@Autowired
// 기존 코드
// private DiscountPolicy discountPolicy
// 필드 명을 빈 이름으로 변경
private DiscountPolicy rateDiscountPolicy 

2. @Qualifier 사용

✔ @Qualifier를 통해 추가구분자를 붙여준다 (빈 이름 변경 x)

빈 등록시 @Qualifier 붙여주기

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

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

주입시에 @Qualifier를 붙여주고 등록한 이름을 적어주기

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

해당 qualifier를 못 찾으면 다시 빈 이름으로 매칭을 하지만 qulifier는 가급적 qualifier끼리 매칭하는 것 권장!

3. @Primary 사용

✔ @Primary: 우선순위 지정

• @Autowired 시에 여러 빈이 매칭되면 @Primary 가 우선권을 가진다

// rateDiscountPolicy 가 우선권을 가진다

@Component
@Primary
public class RateDiscountPolicy implements DiscountPolicy {}

@Component
public class FixDiscountPolicy implements DiscountPolicy {}

Primary vs Qualifier

@Qualifier 의 단점은 주입 받을 때 모든 코드에 @Qualifier를 붙여줘야 한다는 것

메인 커넥션은 @Primary를 활용해 @Qualifier 지정 없이 편하게 조회

서브 커넥션은 @Qualifier를 지정해 명시적으로 커넥션 빈 획득

우선순위

좁은 범위의 @Qualifier가 우선권을 가진다

7. Annotation 직접 만들기

@Qualifier("mainDiscountPolicy")와 같이 문자를 적으면 컴파일시 타입 체크가 안된다

애노테이션을 만들어서 문제 해결

package hello.core.annotation;

import org.springframework.beans.factory.annotation.Qualifier;

import java.lang.annotation.*;

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

annotation 적용

@Component
@MainDiscountPolicy
public class RateDiscountPolicy implements DiscountPolicy {}

// OrderServiceImpl.java

//생성자 자동 주입
@Autowired
public OrderServiceImpl(MemberRepository memberRepository, @MainDiscountPolicy DiscountPolicy discountPolicy) {
    this.memberRepository = memberRepository;
    this.discountPolicy = discountPolicy;
}

annotation에는 상속 기능이 없다

위와 같이 여러 anntotation을 모아서 사용하는 기능은 java가 아니라 스프링에서 지원해주는 기능

다른 annotation도 조합 / 재정의할 수 있으나 가급적 지양

8. List, Map : 조회한 빈이 모두 필요할 때

✔ 의도적으로 해당 타입의 스프링 빈이 모두 필요한 경우 -> List, Map 활용해 전략패턴 구현

ex) 할인 서비스를 제공하는데 클라이언트가 직접 할인의 종류(rate, fix) 선택 가능

예시 코드

package hello.core.autowired;

import hello.core.AutoAppConfig;
import hello.core.discount.DiscountPolicy;
import hello.core.member.Grade;
import hello.core.member.Member;
import hello.core.scan.AutoAppConfigTest;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.stereotype.Component;

import java.util.List;
import java.util.Map;

public class allBeanTest {

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

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

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


    }

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

        @Autowired
        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);
            return discountPolicy.discount(member, price);
        }
    }
}

로직

DiscountService는 Map으로 모든 DiscoutPolicy 주입 받는다 (fixDiscountPolicy & rateDiscountPolicy)

메서드 discount()는 doscountCode로 넘어온 discountPolicy에 맞는 스프링 빈을 찾아서 실행한다

주입

Map<String, DiscountPolicy> : 키에 스프링 빈의 이름을, 값으로 DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아준다.

List<DiscountPolicy> : DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아준다.

만약 해당하는 타입의 스프링 빈이 없으면, 빈 컬렉션이나 Map을 주입

9. 자동, 수동의 올바른 실무 운영 기준

기본으로는 편리한 자동 기능 사용

스프링이 나오고 시간이 지날 수록 자동 선호 추세

@Component 뿐만 아니라 @Controller, @Service , @Repository 처럼 계층에 맞추어 일반적인 애플리케이션 로직을 자동으로 스캔할 수 있도록 지원

스프링부트는 컴포넌트 스캔을 기본으로 사용하고 다른 스프링 빈들도 조건이 맞으면 자동으로 동륵되도록 설계

수동 빈 등록은 로직에 따라 사용

✔ 업무 로직 빈

• 웹을 지원하는 컨트롤러, 핵심 비즈니스 로직이 있는 서비스, 데이터 계층의 로직을 처리하는 리포지토리 등
• 보통 비즈니스 요구사항을 개발할 때 추가되거나 변경

✔ 기술 지원 빈

• 기술적인 문제나 공통 관심사(AOP)를 처리할 때 주로 사용
• 데이터베이스 연결이나,공통 로그 처리처럼 업무 로직을 지원하기 위한 하부 기술이나 공통 기술 등

업무 로직은 숫자도 매우 많고 한번 개발하면 컨트롤러, 서비스, 리포지토리 등 유사한 패턴 존재
-> 자동 기능 사용

기술 지원 로직은 수가 상대적으로 적고, 애플리케이션 전반에 걸쳐 광범위하게 영향을 미치고, 문제 발생 시 디버깅 어려움
-> 수동 빈 등록 사용

✔ 애플리케이션에 광범위하게 영향을 미치는 기술 지원 객체는 수동 빈으로 등록해서 설정 정보에 바로 나타나게 하는 것이 유지보수 하기 좋다

비즈니스 로직 중에서 다형성을 적극 활용할 때

위의 List, Map과 같이 다형성을 적극 활용하는 경우 협업 시에 다른 개발자가 코드를 파악하기 어렵다

✔ 수동 빈으로 등록하거나 자동으로 하면 특정 패키지에 같이 묶어두기

예시 코드

@Configuration
public class DiscountPolicyConfig {

    @Bean
    public DiscountPolicy rateDiscountPolicy() {
        return new RateDiscountPolicy();
    }

    @Bean
    public DiscountPolicy fixDiscountPolicy() {
        return new FixDiscountPolicy();
    }
}

설정 정보와 의존관계 주입 정보가 한 눈에 파악된다