[20230108] 의존관계 자동 주입

[TGKim-Peter]

의존관계 자동 주입

• 의존 관계 주입 방법

  1. 생성자 주입

     • 생성자 통해 의존 관계 주입
     • 생성자 호출 시점에 1번 호출됨
     • 불변, 필수 의존관계에 사용

     ex) Component Annotation을 통해 Spring Bean에 등록되는 시점에 생성자 호출되며 의존 관계 주입

     • 생성자가 1개라면 'Autowired' Annotation이 없어도 자동 Bean 등록

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

     • 'Setter'를 통한 의존 관계 주입 (@Autowired)
     • 선택 및 변경 가능성이 있는 관계에서 사용
     • 주입해야할 대상이 반드시 필요. 그렇지 않은 경우 (@Autowired(required = false))로 지정 필요

  3. 필드 주입

     • 해당 필드에 바로 주입.
     • 코드가 간결하나 DI Framework가 없으면 아무것도 할 수 없음
     • 사용 X

  4. 일반 메서드 주입

     • 일반적으로 잘 사용하지 않지만, 한번에 여러 필드 주입 가능

• 옵션 처리

  • 주입할 Bean이 없을 때, @Autowired(required = false) 사용하거나 @Nullable, Optional <> 사용

• 생성자 주입을 선택해라!

  • 생성자 주입은 객체가 생성될 때 1번만 호출되므로 불변/누락/final 키워드에 장점이 있음
  • 생성자 주입만 final Keyword를 사용할 수있음

• 롬복과 최신 트렌드

  • 코드를 간결하게 할 수 있는 라이브러리이다.
  • @RequiredArgsConstructor 기능을 사용하면 final 이 붙은 필드들을 모아 생성자를 만들어줌

• 조회 빈이 2개 이상일 때,

  • 컴파일 수행 시 NoUniqueBeanDefinitionException 오류가 발생된다.

  위 상황 시 각각의 bean 명도 컴파일 시 알 수 있음.

• @Autowired 필드 명, @Qualifier, @Primary

  • 위와 같이 빈이 2개 이상일때 아래 Annotation을 통해 해결 가능

  1. @Autowired 필드 명 매칭

     • 타입 매칭
     • 타입 매칭 2개 이상 시 필드 명, 파라미터 명으로 Bean 이름 매칭

  2. @Qualifier > @Qualifier끼리 매칭 빈 이름 매칭 > 빈 이름 매칭

     ex) @Qualifier("mainDiscountPolicy")

  3. @Primary 사용

     • Autowired 시 여러 빈이 매칭되면 Primary 가 우선 순위를 가짐
  • Primary와 Qualifier 중복 시에는 Qualifier가 우선 순위를 가져간다.

• 애노테이션 직접 만들기 -- 생략

• 조회한 빈이 모두 필요할 때, List, Map -- 생략

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

  • 편리한 자동 기능을 기준으로 사용
  • 직접 등록하는 기술 지원 객체는 수동 등록
  • 다형성을 활용하는 비즈니스 로직은 수동 등록 고민

[LeeeeDain]

의존관계 자동 주입

주입 방법

• 생성자 주입 (추천방식)
  • 불변, 필수 의존관계에 사용
  • 생성자가 딱 1개만 있으면 @Autowired 생략 가능
  • 테스트코드에서 주입 데이터를 누락했을 때 컴파일 오류가 발생해서 어떤 값을 주입해야하는지 바로 알 수 있음
  • 필드에 final 키워드를 사용할 수 있기 때문에 생성자에서 this.a = a 누락한 오류를 컴파일 시점에 막아줌. 나머지 주입 방식은 생성자 이후에 호출되므로 필드에 final 키워드 사용 불가
  • 프레임워크에 의존하지 않고, 순수한 자바 언어의 특징을 잘 살리는 방법임
  • 기본으로 생성자 주입을 사용하고, 필수 값이 아닌 경우에는 수정자 주입 방식을 옵션으로 부여하면됨
• 수정자 주입 (setter 주입)
  • 변경 가능성이 있는 의존관계에 사용
• 필드 주입
  • 필드에 @Autowired를 붙이는 방법
  • 테스트하기 어려움
  • 실제 빈이 아니라 임의의 빈으로 테스트하고 싶어도 변경할 수 없음
  • 순수한 자바로 테스트할 수 있는 방법이 없음
• 일반 메서드 주입
  • 잘 안씀

옵션 처리

static class TestBean {

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

롬복

• @Getter, @Setter, @ToString 등 유용한 기능 제공

• @RequiredArgsConstructor 를 사용해 생성자 주입도 생략할 수 있음

  • @Component
    @RequiredArgsConstructor    // 생성자 주입 생략해도 있는 것 처럼 동작
    public class OrderServiceImpl implements OrderService {
    
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;
    }

타입이 같은 빈이 2개 이상일 경우

• @Autowired 필드명 매칭

• @Quilifier -> @Quilifier끼리 매칭 -> 빈 이름 매칭

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

  • @Quilifier는 @Quilifier를 찾는 용도로만 사용하는게 좋다.

• @Primary 매칭

  • @Primary가 우선 매칭됨
  • @Quilifier로 명시적으로 호출한게 우선 순위가 더 높음

• 권장 방법

  • 메인쪽에 @Primary 붙여 주고, 서브쪽에 @Quilifier를 지정해 명시적으로 획득하는게 좋음

애노테이션 만들기

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

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

• Map<String, DiscountPolicy> : map의 키에 스프링 빈의 이름을 넣어주고, 그 값으로 DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아준다.
• List\ : DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아준다.

자동 빈 등록 vs 수동 빈 등록

• 편리한 자동 빈 등록을 기본으로 사용하자. @Component 등등...

• 수동 빈 등록을 사용하면 좋은 케이스

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

  • 다형성을 적극 활용한 빈들 한눈에 보기 쉽게 할 때

  • @Configuration
    public class DiscountPolicyConfig {
    @Bean
    public DiscountPolicy rateDiscountPolicy() {
        return new RateDiscountPolicy();
    }
    
    @Bean
    public DiscountPolicy fixDiscountPolicy() {
        return new FixDiscountPolicy();
    }
    }

롬복 사용시 주의사항

• @EqualsAndHashCode : 변경 가능한 객체에서 사용 시, hashCode가 변경되는 이슈
• @RequiredArgsConstructor : 생성자의 파라미터 순서 이슈
• 참고: https://kwonnam.pe.kr/wiki/java/lombok/pitfall
• 특정 어노테이션 사용 금지와 같은 룰을 팀원 모두가 잘 숙지해야 한다는 단점이 있음

[myeongho2]

의존관계 자동 주입

다양한 의존관계 주입 방법

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

생성자 주입

• 특징
  • 생성자 호출 시점에 딱 1번만 호출되는 것이 보장된다.
  • 불변, 필수 의존관계에 사용
  • 생성자가 1개만 있으면 @Autowired 를 생략해도 자동 주입 된다. 스프링 빈( / Component)에만 해당
  • 빈을 등록하면서 주입됨

수정자 주입 (사용하는 경우가 있는가?)

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

    @Autowired(required = false) // 수정자 주입
    public void setMemberRepository(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }
}

• Lifecycle
  • OrderServiceImpl 빈 등록 → 의존관계(Autowired) 주입
• required 옵션을 주어 선택적으로 적용 가능

@Autowired 의 기본 동작은 주입할 대상이 없으면 오류 발생, 주입할 대상이 없어도 동작하게 하려면 @Autowired(required = false) 지정

필드 주입

@Component
public class OrderServiceImpl implements OrderService {

    @Autowired
    private MemberRepository memberRepository;
}

• 특징
  • 안티패턴
  • 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 만 사용하면 required 옵션 default 값이 true 로 되어 있어서 자동 주입 대상이 없으면 오류 발생

자동 주입 대상을 옵션으로 처리하는 방법은 다음과 같다.

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

// 출력 결과
setNoBean2 = null
setNoBean3 = Optional.empty

참고: @Nullable, Optional 은 스프링 전반에 걸쳐서 지원되기 때문에 생성자 자동 주입에서 특정 필드에만 사용해도 된다.

생성자 주입을 선택해라!

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

• final 키워드를 사용하면 객체 생성 안했을 때 컴파일 오류가 발생하여 실수 방지할 수 있음
• 수정자 주입을 포함한 나머지 주입 방식은 생성자 이후에 호출되므로, final 키워드를 사용할 수 없다.
• 생성자 주입 방식을 선택하면 프레임워크에 의존하지 않고, 순수한 자바 언어의 특징을 잘 살리는 방법임
• 생성자 주입과 수정자 주입 동시에 사용할 수 있기 때문에 필수 값이 아닌 경우에 수정자 주입 방식을 옵션으로 부여(진짜?)
• 필드 주입 방식은 사용하지 않는게 좋다.(실제로 이런코드 많음, 보통 @Autowired 어노테이션 지우고 @RequiredArgsConstructor 어노테이션 적용했음)

불변

• 대부분의 의존관계는 애플리케이션 종료 전까지 변하면 안된다.
• 수정자 주입을 사용하면, setXxx 메서드를 public 으로 열어두어야 한다.
• 누군가 실수로 변경할 수 도 있고, 변경하면 안되는 메서드를 열어두는 것은 좋은 설계 방법이 아니다.
• 생성자 주입은 객체를 생성할 때 딱 1번만 호출되므로 이후에 호출되는 일이 없다. 따라서 불변하게 설계할 수 있다.

누락

• 프레임워크 없이 순수한 자바 코드를 단위 테스트 하는 경우에 다음과 같이 수정자 의존관계인 경우

롬복(Lombok)과 최신 트랜드

막상 개발해보면 대부분 불변.. 생성자 주입 자동으로 해줄 수 없을까?

• [start.spring.io](http://start.spring.io/) 에서 프로젝트 생성할 때 dependency 추가 가능
• Plugin 에서 Lombok 추가
• Preferences > Compiler > Annotation Processors 에서 Enable annotation processing 체크
• 대부분 @RequiredArgsConstructor 와 final 키워드 함께 사용

@Autowired 는 타입으로 조회하기 때문에 등록된 Bean 이 2개 이상인 경우 에러 발생

NoUniqueBeanDefinitionException: No qualifying bean of type ..

• 이 때 하위 타입으로 지정하는 것은 DIP 위배, 유연성이 떨어짐

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

• @Autowired 필드 명 매칭

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

  • 필드 명 매칭은 먼저 타입 매칭을 시도 하고 그 결과에 여러 빈이 있을 때 추가로 동작하는 기능이다.
    1. 타입 매칭
    2. 타입 매칭의 결과가 2개 이상일 때 필드 명, 파라미터 명으로 빈 이름 매칭

• @Qualifier 사용

  구분자를 붙여주는 방법

  1. @Qualifier 끼리 매칭 (어디까지 매칭해야 하는가?)
  2. 빈 이름 매칭
  3. NoSuchBeanDefinitionException 예외 발생

• @Primary 사용

  우선순위를 정하는 방법으로 @Autowired 시에 여러 빈 매칭되면 @Primary 가 우선권을 가짐

  • 주로 DB Connection 에서 사용 Main DB 연결시에 사용

우선순위는 @Qualifier 가 @Primary 보다 높다.

• Annotation 방식

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

// 생성자 자동 주입
@Autowired
public OrderServiceImpl(MemberRepository memberRepository,
                        @MainDiscountPolicy DiscountPolicy discountPolicy) {
    this.memberRepository = memberRepository;
    this.discountPolicy = discountPolicy;
}
// 수정자 자동 주입도 사용 가능

애노테이션에는 상속이라는 개념이 없다. 애노테이션을 모아서 사용하는 기능은 스프링이 지원해주는 기능임.

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

스프링을 사용하면 전략 패턴을 간단하게 구현 가능하다.

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

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

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

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

“**편리한 자동 기능을 기본으로 사용하자”**

• 최근 부트는 컴포넌트 스캔을 기본으로 사용, 스프링 부트의 다양한 빈들도 조건이 맞으면 자동으로 등록하도록 설계됨
• 자동 빈 등록을 사용해도 OCP, DIP를 지킬 수 있다.

“그러면 수동 빈 등록은 언제 사용하면 좋을까?”

• 기술 지원 빈의 경우 광범위하게 영향을 미치기 때문에 수동 빈으로 드러내는 것이 좋음

• 비즈니스 로직 중 다형성을 적극 활용할 때 특정 패키지에 같이 묶어 두는게 좋다. 딱 보고 이해가 되서 유지보수 용이함

  @Configuration
  public class DiscountPolicyConfig {
  
      @Bean
      public DiscountPolicy rateDiscountPolicy() {
          return new RateDiscountPolicy();
      }
      @Bean
      public DiscountPolicy fixDiscountPolicy() {
          return new FixDiscountPolicy();
      }    
  }

“정리”

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

직접 등록하는 기술 지원 객체는 수동 등록

다형성을 적극 활용하는 비즈니스 로직은 수동 등록을 고민해보자

[sixhustle]

@myeongho2 aws sdk bean 생성할 때, 주입코드 공유

[myeongho2]

• local, test

  @Profile({"local", "test"})
  @Configuration
  public class LocalS3Config {
  @Value("${aws.s3.region}")
  private String region;
  
  @Value("${aws.s3.bucket}")
  private String bucket;
  
  @Bean(initMethod = "start", destroyMethod = "stop")
  public S3Mock s3Mock() {
      return new S3Mock.Builder().withPort(port).withInMemoryBackend().build();
  }
  
  @Bean
  public S3Client amazonS3(S3Mock s3Mock) {
      S3Client client = S3Client.builder()
          ... // region, endpoint, bucket settings...
      return client;
  }
  }

  ---

@Configuration
@Profile({"!local"})
public class S3Config {

    @Value("${aws.s3.region:us-east-1}")
    private String region;

    @Bean(destroyMethod = "close")
    public S3Client s3Client() {
        return S3Client.builder().region(Region.of(region)).build();
    }
}