[DEV-29] CalculateDetailGraduationUseCaseResolver 구현 #252
Conversation
5uhwann
changed the title
5uhwann
changed the title
5uhwann
changed the title
| private void initCalculateDetailGraduationUseCase() { | ||
| Map<String, CalculateDetailGraduationUseCase> matchingBeans = applicationContext.getBeansOfType( | ||
| CalculateDetailGraduationUseCase.class); | ||
| this.calculateDetailGraduationUseCases = new ArrayList<>(matchingBeans.values()); | ||
| } |
There was a problem hiding this comment.
이 코드만 보면 생성자 주입으로 모든 CalculateDetailGraduationUseCase의 빈을 주입하는 것과 큰 차이는 없어보이는데, ApplicationContext를 사용함으로서 얻는 장점이 있나?
There was a problem hiding this comment.
생각해보니 그렇네요..! 빈 조회 후 특정 방법에 대한 정렬이나 기본 빈 처리 전략 없이 해당 타입으로만 조회를 하니 List로 주입받는것과 다름이 없군요
원래는 GraduationCategory에 해당하는 빈만 조회하고 싶었는데 className 기반으로 조회를 할 경우 변경에 대한 유연성이 너무떨어져 해당 방식은 기각했는데 그렇다면 각 CalculateDetailGraduationUseCase 빈 등록시 @Quilipier를 통해 GraduationCategory EnumType value로 구분자를 추가하여 등록 후 GraduationCategory에 해당하는 빈만 조회하여 반환하는 방식은 어떤가요?
- 모든 빈 List로 주입 후 support 여부로 체크 후 반환
- 코드가 간결해짐
- CalculateDetailGraduationUseCase 타입 빈들을 모두 체크해야 함 (어차피 몇개 없어서 큰 문제는 아닌거 같긴 합니다)
- Qualifier 어노테이션을 통해 빈 등록 시 GraduationCategory enum value로 구분 후 GraduationCategory에 해당하는 빈 조회
- 필요한 빈만 조회 후 반환 가능
- GraduationCategory 변경 시 Qualifier 어노테이션 value 수정 필요 -> 마찬가지로 변경의 유연성 떨어짐
There was a problem hiding this comment.
나는 1번 방안이 더 나은거 같아. 수환 말대로 className 기발 조회가 변경 유연성이 떨어지고, 모든 빈을 주입하는게 큰 차이가 없다는 점에서!
|
5uhwann
deleted the
feature/DEV-29-calculate_detail_graduation_usecase_resolver
branch
✅ 작업 내용
해당 PR에서 논의한 내용을 바탕으로 CalculateDetailGraduationUseCaseResolver를 새로 구현하였습니다.
🤔 고민 했던 부분
위 사항을 반영하여 수정한 다이어그램입니다.
🔊 도움이 필요한 부분!!