당니의 개발자 스토리
애노테이션 직접 만들기 본문
애노테이션 직접 만들기
이번 시간에는 애노테이션을 직접 만들어 보겠습니다. 이것도 실무에서 한 번씩 사용하기 때문에 한번 보여드릴게요.

이전 시간에 @Qualifier를 배울 때 @Qualifier("mainDiscountPolicy") 이런 식으로 만들었는데, 여기에 문제가 한 가지 있어요. mainDiscountPolicy는 문자잖아요. 문자는 컴파일 타입 체크가 안 돼요.
그래서 annotation을 만들어서 좀 더 깔끔하게 운영할 수 있는 방법이 있습니다. 한번 보여드릴게요.
먼저 core에다가 annotation 이라는 패키지를 만들게요.

여기에다가 첫 번째로 MainDiscountPolicy 라는 애노테이션을 만들겠습니다.

애노테이션을 만들었는데, 만약 클래스로 만들었다고 해도

이걸 붙여주시면 애노테이션이 됩니다.
이거를 @Qualifier 처럼 똑같이 붙일 수 있게 할 거죠. 그러면 cmd + O 해서 @Qualifier를 검색해서,

Target을 보면, 필드에다가도 붙일 수 있고 메서드에다가도 붙일 수 있고, 이런 뜻이거든요.

그러면 여기까지 다 복사해서, 우리 애노테이션에다가 그대로 옮깁니다. 그리고 한 가지 더,

@Qualifier("mainDiscountPolicy")를 적어줍니다. 그러면 이 MainDiscountPolicy 라는 애노테이션을 쓰면, 스프링 컨테이너 안에서는

이 기능들이 다 동작하는 겁니다.
이제 RateDiscountPolicy에 들어가셔서,

원래는 우리가 이런 식으로 했었는데, 이게 문자이기 때문에

이래버려도 동작한단 말이에요. 그런데 막상 실행시켜보면 오류가 나겠죠. 문자기 때문에 컴파일 에러로 잡을 수가 없습니다.
이걸 깔끔하게 해결하기 위해서는, 우리가 만든 @MainDiscountPolicy를 적어주는 겁니다.

그러면 MainDiscountPolicy를 MainnDiscountPolicy으로 잘못친다고 해도 컴파일 에러로 오류를 잡을 수 있겠죠.
그리고 나서, @MainDiscountPolicy를 가져다 쓰는 곳인 OrderServiceImpl에다가도 적어줘야겠죠.

이렇게 하면, MainDiscountPolicy 안에

@Qualifier("mainDiscountPolicy")를 지정해주는 애노테이션이 있기 때문에, 이 코드를 적어준 것과 같은 효과를 발휘합니다. '어? 그냥 @Qualifier("mainDiscountPolicy")만 적어줘도 되지 않나요?' 라고 할 수 있는데 안됩니다. 우리가 전에 말했다시피, 애노테이션이 상속관계라는 게 없다고 했죠.

따라서, 위의 4가지 애노테이션들 자체는 @Qualifier 기능이지, @Qualifier("mainDiscountPolicy")를 적어준다고 해서 이게 @MainDiscountPolicy의 기능이 되진 않아요. 그래서 따로 또 적어줘야 되는 겁니다.

그래서 이렇게 하고 돌려보면 테스트가 다 성공하죠.
그래서 생성자 자동주입에서 성공했고 수정자 같은 경우에도 @MainDiscountPolicy를 써주시면 됩니다.
간단하다 보니까, @MainDB 이런 식으로 애노테이션을 직접 만들어 가지고 많이 운영을 합니다.
그런데 @Primary로 해결할 수 있으면, @Primary를 쓰는게 낫구요. 그게 아니고 좀 다양한 상황이면 이렇게 해결하는 것도 괜찮습니다.

그리고 cmd + B 하면, 이 애노테이션을 사용하는 코드를 추적하기가 편합니다.
그래서 정리를 해보면,

애노테이션에는 상속이나 포함하는 개념이 없어요. 이렇게 여러 애노테이션을 모아서 사용하는 기능은 스프링이 지원해주는 기능인 거예요.

스프링이 @MainDiscountPolicy을 발견하면, 얘를 까봐서

'오 @Qualifier("mainDiscountPolicy")가 있군' 하고 인식을 하는 거예요.
원래 java에서 지원하는 기능이 아니에요. 그리고 @Qualifier 뿐만 아니라 다른 애노테이션들도 함께 조합해서 사용할 수 있어요. 단적으로 @Autowired도 재정의 할 수 있습니다.
물론 스프링이 제공하는 기능을 뚜렷한 목적 없이 무분별하게 재정의 하는 것은 유지보수에 더 혼란만 가중할 수 있습니다.
웬만한 거는 스프링이 제공하는 애노테이션으로 다 해결이 되거든요. 너무 무분별하게 쓰진 맙시다.
다음 시간에는 조회한 빈이 모두 필요할 때를 볼 건데요. 스프링 컨테이너에서 빈 조회할 때도 비슷한 걸 했었죠.
자동으로 의존관계 주입할 때도 내가 딱 선택해서 하나만 빈을 조회하는 게 아니라, '이 타입과 관련된 애들은 다 조회하고 싶어!' 이런 거 할 때 어떻게 하는지 알려드리겠습니다.
'스프링 > 스프링 핵심 원리 - 기본편' 카테고리의 다른 글
| 자동, 수동의 올바른 실무 운영 기준 (0) | 2024.01.26 |
|---|---|
| 조회한 빈이 모두 필요할 때, List, Map (0) | 2024.01.25 |
| @Autowired 필드 명, @Qualifier, @Primary (0) | 2024.01.24 |
| 조회 빈이 2개 이상 - 문제 (0) | 2024.01.24 |
| 롬복과 최신 트랜드 (0) | 2024.01.24 |