Automatic injection of dependencies

스프링의 의존관계 자동 주입에 대해 정리하였습니다.

 

 

---

< 다양한 의존관계 주입 방법 >

Spring에서는 의존성 주입(Dependency Injection)이라는 개념을 통해 객체 간의 관계를 설정하고, 객체간의 의존성을 관리합니다.

 

 

---

#1 생성자 주입

: 객체가 생성될 때 의존성을 주입하는 방법입니다. 생성자의 매개변수로 필요한 의존 객체를 전달합니다.

• 생성자 호출시점에 딱 1번만 호출되는 것이 보장되므로, 불변 & 필수 의존관계에 사용합니다.

@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개만 있다면, @Autowired를 생략해도 됩니다.

@Component
public class OrderServiceImpl implements OrderService {

    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

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

 

 

---

#2 수정자(setter) 주입

: 객체 생성 후 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;
    }
}

 

+. @Autowired의 기본 동작은 주입할 대상이 없는 경우 오류가 발생합니다. 주입할 대상이 없어도 동작하게 하고 싶은 경우 @Autowired(required = false)로 지정하면 됩니다.

 

 

< 자바빈 프로퍼티 >
자바는 과거부터 필드의 값을 직접 변경하지 않고, setXxx, getXxx라는 메서드를 통해 값을 읽거나 수정하도록 하는 규칙을 만들었는데, 그것을 자바빈 프로퍼티 규약이라고 합니다.

class Data{
    private int age;
    
    public void setAge(int age){
        this.age = age;
    }
    
    public int getAge(){
        return age;
    }
}​

 

 

---

#3 필드 주입

: 필드에 직접 `@Autowired` 애노테이션을 사용하여 의존성을 주입하는 방법입니다.

• 가장 간단한 방법이지만, 한 번 의존관계를 주입한 이후에 다시 접근할 방법이 없어 테스트하기 어렵고, Spring이 아닌 환경에서 사용이 어렵습니다.
• 권장되는 방식이 아닙니다.

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

 

 

어쩌면 당연한 이야기이지만, 의존관계 자동 주입은 스프링 컨테이너가 관리하는 스프링 빈이어야 동작합니다. 스프링 빈이 아닌 Member 같은 클래스에서 @Autowired를 작성해도 아무런 기능도 동작하지 않습니다.

 

 

---

< 옵션 처리 >

스프링에서는 자동 주입을 할 때, 빈이 존재하지 않더라도 정상적으로 동작하도록 설정할 수 있습니다. 예를 들어, 특정 상황에서는 주입할 스프링 빈이 없어도 기본 동작을 하도록 구현해야 할 경우가 있습니다.
하지만, `@Autowired`를 사용하면 기본적으로 `required` 옵션이 `true`로 설정되어 있어, 자동 주입 대상이 없으면 오류가 발생합니다. 이러한 오류를 피하고 자동 주입 대상을 선택적으로 처리하기 위해 다음과 같은 옵션을 사용할 수 있습니다:

 

• @Autowired(required=false) : 자동 주입할 대상이 없으면 해당 수정자 메서드(setter)가 호출되지 않습니다.
• org.springframework.lang.@Nullable : 자동 주입할 대상이 없으면 `null`이 주입됩니다.
• java.util.Optional<T> : 자동 주입할 대상이 없으면 `Optional.empty`가 주입됩니다.

 

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

    static class TestBean {
        @Autowired(required = false)
        public void setNoBean1(Member noBean1) {
            System.out.println("noBean1 = "+ noBean1);
        }

        @Autowired
        public void setNoBean2(@Nullable Member noBean2) {
            System.out.println("noBean2 = "+ noBean2);
        }

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

 

결과

 

 

 

---

< 생성자 주입을 선택하라 >

과거에는 수정자 주입과 필드 주입을 많이 사용했지만, 최근에는 스프링을 포함한 DI 프레임워크 대부분이 생성자 주입을 권장합니다. 그 이유는 다음과 같습니다.

 

• 대부분의 의존관계 주입은 애플리케이션이 종료될 때까지 변경되지 않습니다. 오히려 이러한 의존관계는 변하지 않고 불변성을 유지해야 합니다.
• 수정자 주입을 사용하면 `setXxx` 메서드를 `public`으로 공개해야 하므로, 외부에서 임의로 수정할 수 있는 가능성이 열리게 됩니다.
  
• 의도치 않은 변경을 방지하려면, 변경해서는 안 되는 메서드를 공개하지 않는 것이 좋은 설계입니다.
• 생성자 주입은 객체가 생성될 때 단 한 번만 호출되므로 이후에 다시 호출되지 않습니다. 따라서 객체를 불변하게 설계할 수 있습니다.

 

 

---

[ 수정자 주입의 문제점 ]

: 수정자 주입을 이용하는 경우 스프링 컨테이너 없이 순수한 자바 코드만을 이용해 테스트하면, 의존관계의 주입이 없더라도 컴파일 시점에서 문제를 알아차릴 수 없습니다. (스프링 프레임워크 사용시에는 문제되지 않습니다.)

 

Test)

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

    //...
}

@Test
void createOrder() {
    OrderServiceImpl orderService = new OrderServiceImpl();
    orderService.createOrder(1L, "itemA", 10000);
}

: 위의 테스트가 실행은 되지만, 막상 실행 결과는 NPE(Null Point Exception)이 발생합니다. memberRepository, discountPolicy 모두 의존관계 주입이 누락되었기 때문입니다.

 

반면, 생성자 주입을 사용하면 주입 데이터를 누락 했을 때 컴파일 오류가 발생하고, 추가적으로 final 키워드를 사용해 생성자에서 값이 설정되지 않을 경우 컴파일 시점에 오류가 발생하여 이를 방지할 수 있습니다.

 

 

정리하자면, 

• 생성자 주입은 프레임워크에 의존하지 않고 자바의 장점을 잘 살릴 수 있는 방법입니다.
• 기본적으로 생성자 주입을 사용하되, 필수적이지 않은 값은 옵션으로 수정자 주입을 활용할 수 있습니다. 두 방식을 함께 사용할 수 있습니다.
• 주로 생성자 주입을 선택하고, 필요한 경우에만 수정자 주입을 사용하세요. 필드 주입은 피하는 것이 좋습니다.

 

 

---

< Lombok과 최신 트렌드 >

개발 시 대부분의 객체는 불변이기 때문에 필드에 `final` 키워드를 자주 사용합니다. 하지만 생성자를 작성하고 값을 대입하는 과정이 번거로울 수 있습니다. 이럴 때는 필드 주입처럼 간편하고 깔끔하게 코드를 작성할 수 있도록 Lombok 라이브러리를 활용하면 좋습니다.

 

Ex)

기본 생성자 주입 코드 :

@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개이기 때문에 @Autowired를 생략할 수 있습니다.

 

Lombok의 @RequiredArgsConstructor 활용 코드 :

@Component
@RequiredArgsConstructor
public class OrderServiceImpl implements OrderService {

    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;
}

 

: 위 두가지 코드는 완전히 동일합니다. Lombok은 자바의 애노테이션 프로세서를 이용해 컴파일 시점에 생성자 코드를 자동으로 생성해줍니다. 실제로 클래스 파일을 열어보면 아래와 같은 코드가 추가된 것을 확인할 수 있습니다.

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

 

 

최근에는 생성자를 하나만 두고 @Autowired를 생략하는 방법이 많이 사용됩니다. 추가로 Lombok의 @RequiredArgsConstructor를 활용하여 코드를 깔끔하게 유지하는 방법이 선호됩니다.

 

 

---

< 조회한 빈이 2개 이상일 경우 >

@Autowired는 타입으로 빈을 조회하기 때문에, 동일한 타입의 빈이 여러 개 있으면 문제가 발생합니다.

 

@Autowired
private DiscountPolicy discountPolicy

@Autowired는 타입으로 빈을 조회하기 때문에, 아래 코드와 유사하게 동작합니다.

ac.getBean(DiscountPolicy.class)

 

여기서, DiscountPolicy의 하위 타입인 FixDiscountPolicy, RateDiscountPolicy 둘다 스프링 빈으로 선언 후 의존관계 자동 주입을 실행하면 NoUniqueBeanDefinitionException 오류가 발생합니다.

@Component
public class FixDiscountPolicy implements DiscountPolicy {}

@Component
public class RateDiscountPolicy implements DiscountPolicy {}

@Autowired
private DiscountPolicy discountPolicy

 

에러 :

NoUniqueBeanDefinitionException: No qualifying bean of type 'hello.core.discount.DiscountPolicy' available

: 한 개의 빈을 기대했지만, `fixDiscountPolicy`와 `rateDiscountPolicy` 두 개가 발견되었다고 알립니다.

 

이 문제를 해결하기 위해

1. 하위 타입으로 지정할 수 있지만, 이는 DIP(의존성 역전 원칙)를 위배하고 유연성을 떨어뜨리고 이름만 다른 같은 타입의 빈 두 개가 있을 경우에도 해결되지 않습니다.

2. 스프링 빈을 수동으로 등록하는 방법도 있지만, 수동으로 일일이 예외처리 하기 번거롭습니다.

 

이를 의존관계 자동 주입 단계에서 해결할 수 있는 다른 방법들을 소개합니다.

 

 

---

#1 @Autowired 필드 명 매칭

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

 

기존 코드 :

@Autowired
private DiscountPolicy discountPolicy

 

# 방법 1 : 필드 명을 빈 이름으로 변경

@Autowired
private DiscountPolicy rateDiscountPolicy

: 필드 명이 rateDiscountPolicy이므로 정상 주입됩니다.

 

필드 명 매칭은 먼저 타입 매칭을 시도 하고 그 결과에 여러 빈이 있을 때 추가로 동작하는 기능입니다.

 

 

# 방법 2 : 필드 인젝션

@Autowired
public OrderServiceImple(MemberRepository memberRepository, DiscountPolicy rateDiscountPolicy) {
	this.memberRepository = memberRepository;
    this.discountPolicy = rateDiscountPolicy;
}

: 파라미터 명이 rateDiscountPolicy이므로 정상 주입됩니다.

 

 

@Autowired는 타입 매칭의 결과가 2개 이상일 경우, 필드 명 또는 파라미터 명으로 빈 이름을 매칭합니다.

 

 

---

#2 @Qualifier

: 빈을 주입할 때 추가적인 구분자를 제공하는 방법입니다. 이는 주입 시에만 사용되는 것이며, 빈의 이름을 변경하는 것이 아닙니다.

 

1. 빈 등록 시에 @Qualifier키워드를 붙여줍니다.

 

Ex)

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

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

 

2. 주입시에 등록한 @Qualifier를 적어줍니다.

 

Ex) 생성자 자동 주입 :

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

 

Ex) 수정자 자동 주입 :

@Autowired
public DiscountPolicy setDiscountPolicy(@Qualifier("mainDiscountPolicy") DiscountPolicy discountPolicy) {
    this.discountPolicy = discountPolicy;
}

 

Ex) 직접 빈 등록

@Bean
@Qualifier("mainDiscountPolicy")
public DiscountPolicy discountPolicy() {
    return new ...
}

 

 

---

#3 @Primary

: @Primary는 빈의 우선순위를 설정하는 방법입니다. @Autowired로 여러 빈이 매칭될 때, @Primary가 지정된 빈이 우선 선택됩니다.

 

Ex)

@Component
@Primary
public class RateDiscountPolicy implements DiscountPolicy {}

@Component
public class FixDiscountPolicy implements DiscountPolicy {}

 

 

< @Primary와 @Qualifier의 활용 >
코드에서 자주 사용하는 메인 데이터베이스 커넥션 빈과 가끔 사용하는 서브 데이터베이스 커넥션 빈이 있다고 가정해봅시다. 메인 데이터베이스 빈은 `@Primary`를 적용하여, 조회 시 `@Qualifier`를 지정하지 않고도 편리하게 사용할 수 있습니다. 서브 데이터베이스 빈은 `@Qualifier`를 사용하여 명시적으로 조회하는 방식으로 사용하면 코드를 깔끔하게 유지할 수 있습니다. 이때, 메인 데이터베이스 빈에 `@Qualifier`를 지정해도 문제가 없습니다.

 

 

< 우선순위 >
`@Primary`는 기본값처럼 동작하고, `@Qualifier`는 보다 구체적으로 동작합니다. 이 두 가지 중 어떤 것이 우선할까요? 스프링에서는 자동보다는 수동, 넓은 범위보다는 좁은 범위의 선택이 우선입니다. 따라서 이 경우 `@Qualifier`가 우선권을 가집니다.

 

 

---

< 애노테이션 직접 만들기 >

앞서 `@Qualifier`를 사용하여 추가 구분자를 부여할 수 있었습니다. 그러나 이 구분자는 문자열로 지정되기 때문에, 컴파일 시 타입 체크가 되지 않아 오타 등으로 인한 오류를 사전에 발견하기 어렵다는 문제가 있습니다.
이럴 땐, 어노테이션을 직접 만들어 문제를 해결하는 방법도 존재합니다.

 

Ex) MainDiscountPolicy 만들기

package hello.core.annotataion;

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

}

: 새로 만든 어노테이션이 @Qualifier를 포함하고 있는 구조입니다.

 

이렇게 만든 어노테이션을 추가 구분자를 부여하고 싶은 스프링 빈에 작성해주면 됩니다.

@Component
@MainDiscountPolicy
public class RateDiscountPolicy implements DiscountPolicy {}

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

//수정자 자동 주입
@Autowired
public DiscountPolicy setDiscountPolicy(@MainDiscountPolicy DiscountPolicy discountPolicy) {
    this.discountPolicy = discountPolicy;
}

 

+. 애노테이션에는 상속 개념이 없습니다. 여러 애노테이션을 조합해서 사용하는 기능은 스프링에서 지원합니다.

`@Qualifier`뿐만 아니라, 다른 애노테이션들도 함께 조합할 수 있습니다. 심지어 `@Autowired`도 재정의할 수 있습니다.

그러나 스프링에서 제공하는 기능을 명확한 목적 없이 무분별하게 재정의하면 유지보수에 혼란을 초래할 수 있습니다.

 

 

---

< 조회한 빈이 모두 필요할 때 : Map, List >

때로는 특정 타입의 스프링 빈을 모두 사용해야 하는 경우가 있습니다. 예를 들어 할인 서비스를 제공할 때, 사용자가 할인의 종류(rate, fix)를 선택할 수 있는 서비스가 필요할 수 있습니다.

 

Ex)

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

: 위 코드에서 봐야 할 것은 의존관계 주입의 대상이 기존처럼 단일 객체가 아니라, Map과 List 자료구조로 변경되었다는 점입니다.

이렇게 Map 또는 List로 의존관계 주입의 대상을 설정하는 경우 타입으로 조회한 스프링 빈이 한 개가 아니어도 조회된 모든 빈에 대해서 의존관계 주입이 이루어집니다.

 

: 이렇게 여러 개의 스프링 빈이 의존관계로 주입됩니다.

 

 

테스트 코드 :

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

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

: 위와 같이 이렇게 코드를 구성하면, 클라이언트의 입장에서 할인 전략을 선택하는 프로그램을 쉽게 구현할 수 있습니다.

 

 

로직 분석

• DiscountService는 Map으로 모든 DiscountPolicy를 주입받습니다. 이때 fixDiscountPolicy, rateDiscountPolicy가 주입됩니다.
• discount() method는 discountCode로 "fixDiscountPolicy"가 넘어오면, Map 자료구조에서 fixDiscountPolicy 스프링 빈을 찾아 실행합니다. 이는 rateDiscountPolicy에도 똑같이 적용됩니다.

주입 분석

• Map<String, DiscountPolicy>: map의 키에 스프링 빈의 이름을 넣어주고, 그 값으로 DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아줍니다.
• List<DiscountPolicy>: DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아줍니다.
• 만약 해당하는 타입의 스프링 빈이 없다면, 빈 컬렉션이나 Map을 주입합니다.

 

 

---

< 자동, 수동의 올바른 실무 운영 기준 >

편리한 자동 기능을 기본으로 사용하자!

그러면 어떤 경우에 컴포넌트 스캔과 자동 주입을 사용하고, 어떤 경우에 설정 정보를 통해서 수동으로 빈을 등록하고, 의존관계도 수동으로 주입해야 할까요?

 

결론부터 이야기하면, 스프링이 나오고 시간이 지날수록 자동 등록을 선호하는 추세입니다.

 

스프링은 자동으로 @Component, @Controller, @Service, @Repository 등을 스캔하여 빈을 등록하며, 이 방식은 개발자가 직접 빈을 관리해야 하는 수고를 덜어줍니다. 설정 정보를 기반으로 애플리케이션을 구성하는 부분과 실제 동작하는 부분을 명확히 구분하는 것이 이상적이지만, 자동 등록은 이러한 프로세스를 많이 간소화해 줍니다.

 

또한, 결정적으로 자동 등록 방식을 이용해도 OCP와 DIP 같은 객체지향 원칙을 준수할 수 있습니다.

 

---

수동 빈 등록은 언제 사용하면 좋은 걸까?

애플리케이션 로직은 크게 두 가지로 나눌 수 있습니다:

 

1. 업무 로직 빈

: 웹을 지원하는 컨트롤러, 핵심 비즈니스 로직을 담당하는 서비스, 데이터 계층을 처리하는 레포지토리가 포함됩니다. 보통 비즈니스 요구사항에 따라 추가되거나 변경됩니다.

 

→ 업무 로직은 숫자도 매우 많고, 컨트롤러, 서비스, 레포지토리 같은 유사한 패턴을 가집니다. 이런 경우 자동 기능을 적극 활용하는 것이 좋습니다. 문제가 발생해도 어디서 발생했는지 파악하기 쉽기 때문입니다.

 

2. 기술 지원 빈

: 기술 문제나 공통 관심사(AOP)를 처리하는 용도로, 데이터베이스 연결, 공통 로그 처리 등 업무 로직을 지원하기 위한 하부 기술이나 공통 기술들입니다.

 

→ 기술 지원 로직은 업무 로직과 비교해서 수가 적고, 애플리케이션 전반에 걸쳐 광범위한 영향을 미칩니다. 그리고 기술 지원 로직은 문제 발생 시 어떤 부분에서 문제가 생겼는지 파악하기 어렵고, 심지어 올바르게 동작하고 있는지 확인이 힘든 경우가 많습니다.

따라서, 기술 지원 로직은 명확하게 드러나도록 수동으로 빈을 등록하는 것이 좋습니다. 이는 유지보수에도 용이합니다.

 

 

---

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

<의존관계 자동 주입 - 조회한 빈이 모두 필요할 때, List, Map>을 다시 봅시다.

 

DiscountService가 의존관계 자동 주입으로 Map에 주입을 받는 상황을 생각해 보면 여기에 어떤 빈들이 주입될지, 각 빈들의 이름은 무엇일지 코드만 보고 한 번에 쉽게 파악할 수 있을까요? 내가 개발했으니 크게 관계가 없지만, 만약 이 코드를 다른 개발자가 개발해서 나에게 준 것이라면 어떨까요?

 

자동 등록을 사용하고 있기 때문에 파악하려면 여러 코드를 찾아봐야 하는 번거로움이 발생합니다.

이런 경우 수동 빈으로 등록하거나 또는 자동으로 하면 특정 패키지에 같이 묶어두는 게 좋습니다. 핵심은 한번에 보고 이해가 되는 것이 중요합니다!

 

이 부분을 별도의 설정 정보로 만들고 수동으로 등록하면 다음과 같습니다.

@Configuration
public class DiscountPolicyConfig {

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

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

: 이렇게 하면, 해당 설정 정보만 봐도 한눈에 빈의 이름은 물론이고, 어떤 빈들이 주입될지 파악할 수 있습니다.

 

그럼에도 불구하고 이와 같은 상황에서 빈 자동 등록을 사용하고 싶다면, 파악하기 좋게 DiscountPolicy의 구현 빈들만 따로 모아서 특정 패키지에 모아둡시다.

 

 

 

 

 

---

해당 글에 포함된 코드나 그림은 김영한님이 제공해주신 자료를 바탕으로 작성되었습니다.

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

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