스프링 핵심 원리 - 의존관계 자동 주입(DI)

링딩·2022년 7월 12일
0

Spring 공부

목록 보기
3/3




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

DI(Dependency Injection)란?

◽ 정의

DI란 의존성 주입이라 부르며, 객체를 직접 생성하는 게 아닌 외부(IOC 컨테이너)에서 생성한 후 주입시켜주는 방식이다.

의존성 주입 방식으로는 3가지 방법이 존재

  • 생성자 주입
  • 수정자 주입(setter 주입)
  • 필드 주입
  • 일반 메서드 주입

🎉 생성자 주입

  • 우리가 주로 진행한 방식임
  • 생성자 호출시점에 딱 1번만 호출되는 것이 보장
  • 불변, 필수 의존관계에 사용 (null 이나 비워두어선 안됨)
  • 생성자가 1개 밖에 없다면 @Autowired 생략해도 자동 주입이 가능.
@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;
 	}
}

🎉 수정자 주입(setter주입)

  • 선택, 변경 가능성이 있는 의존관계에 사용
  • @Autowired의 기본동작은 주입 대상이 없다면 오류가 발생 -> @Autowired(required = false) 지정해주면 해결
@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;
 	}
}

🎉 필드 주입

  • 코드는 간결, but 외부에서 변경이 불가능 => DI 프레임워크가 없으면 아무것도 할 수 없음.
  • 사용하지 말길...(굳이 쓴다면 테스트 코드)
@Autowired
private MemberRepository memberRepository;

@Autowired
private DiscountPolicy discountPolicy;

🎉 일반 메서드 주입 (잘 사용 x)

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


+) 옵션처리

: 주입할 스프링 빈 없이도 동작해야 할 때가 있다. 그리고, @Autowired의 required=true라면 자동주입 대상이 없을 시 오류가 발생해버린다...

자동 주입 대상을 옵션으로 처리하는 방법

  • @Autowired(required = false)
    -> 수정자 메서드 자체가 호출 x , 주입할 대상이 없어도 동작 가능.
  • 매개변수에 @Nullable
    -> 호출은 되지만 자동 주입 대상이 없으면 null이 입력
  • Optional<>
    -> 자동 주입 대상이 없다면, Optional.empty 이 호출된다.

2. 생성자 주입을 추천

+) 의존성과 설정값을 생성자 인자로 주입해야 하는 이유에 대해 설명해주세요.

왜 추천할까?

1. 불변

  • 생성자 주입은 객체 생성 때 단 1번만 호출된다.
    =>즉, 종료 시점까지 의존관계가 변경되지 않으며 다시 호출될 일이 없다.

2. final

  • 오로지 생성자 주입만 사용 가능하며 값이 설정되지 않는 부분을 알려준다.
    => 컴파일 시점에 오류를 막을 수 있다.

3. 누락

  • 데이터를 누락 했을 때 컴파일 오류를 발생시킨다
  • IDE를 통해 어떤 값을 필수로 주입해야 하는지 알려준다.





3. 요즘 추세는 Lombok이래

더 간결해진 요즘 추세는...

기본 코드

수정된 코드 (생성자 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;
 }
}

✨롬복까지 추가한 수정된 코드 (매우 깨끗)

이로써 롬복이 컴파일 시점에서 @RequiredArgsConstructor을 통해 final이 붙은 필드를 모아서 생성자 코드'를 자동으로 생성 한다.






@Autowired 필드명, @Qualifier, @Primary

  • 조회 대상 빈이 2개 이상일 때 해결법
  1. @Autowired 필드 명, 파라미터 명 매칭
  2. @Qualifier -@Qualifier 끼리 매칭
  3. @Primary 사용


1. @Autowired 매칭정리

  1. 타입 매칭
  2. 타입 매칭의 결과가 2개 이상?
    • 필드 명, 파라미터 명으로 '빈 이름'으로 매칭함.

2. @Qualifier

  1. @Qualifier끼리 매칭
  2. 빈 이름 매칭
  3. NoSuchBeanDefinitionException 예외 발생

✔방법 (코드)

+) 만약 @Qulifier로 주입하는데 @Qualifier("mainDiscountPolicy") 를 못 찾으면...

  • 저 이름의 '스프링 빈'을 추가로 찾는다.

3. @Primary

: @Autowired로 인해 여러 개의 빈이 나오게 된다면, 이 어노테이션을 통해서 우선권을 준다.

그러면 @Primary와 @Qualifier의 차이는?

스프링은 1) 자동 < 수동
2) 넓은 범위 > 좁은 범위
3) @Primary < @Qualifier



애노테이션 만들기

: @Qualifier 물론 좋다.. 그러나 얘는 문자라 컴파일 시 '타입 체크'가 안되기에... 그냥 만들자

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

이렇게 쓰인다.

@Component
@MainDiscountPolicy
public class RateDiscountPolicy implements DiscountPolicy {
}
@Component
public class OrderServiceImpl implements OrderService {

    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

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

조회한 Bean이 모두 필요할 때 (Feat. List, Map) [이해가 잘 안 가는 부분]

의도적으로 정말 해당 타입의 스프링 빈이 다 필요한 경우도 있다.

예를 들어서 할인 서비스를 제공하는데, 클라이언트가 할인의 종류(rate, fix)를 선택할 수 있다고 가정해보자.

스프링을 사용하면 소위 말하는 전략 패턴을 매우 간단하게 구현할 수 있다.

public class AllBeanTest {
 @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);
 }
 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);
 }
 }

출처

jkijki12님의 글을 참조하여 작성하였습니다.

profile
초짜 백엔드 개린이

0개의 댓글