inflearn logo
강의

강의

N
챌린지

챌린지

멘토링

멘토링

N
클립

클립

로드맵

로드맵

지식공유

스프링 핵심 원리 - 기본편

애노테이션 직접 만들기

실무에서 RequiredArgsConstructor를 사용할 때의 Annotation 사용 유무

554

민설

작성한 질문수 2

0

[질문 템플릿]
1. 강의 내용과 관련된 질문인가요? 예
2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예
3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예

[질문 내용]
안녕하세요. Lombok의 RequiredArgsConstructor를
https://www.inflearn.com/questions/71872/requiredargsconstructor%EA%B3%BC-qualifier%EC%A7%88%EB%AC%B8
저와 비슷한 질문이 있을까봐 질문 게시판을 찾다가 위의 글을 익어보았습니다.

실무에서도 저렇게 Lombok 설정을 바꾼 다음에 Primary, Qualifier, 혹은 사용자 정의 Annotation을 필드 앞에 적는 방식을 주로 사용하나요? 저러면 개발 팀 전체의 Lombok 설정이 바뀌는 것인데, 보통 저걸 합의하고 저렇게 바꾸는지 여쭤보고 싶습니다.

아니면 실무에서는 Primary, Qualifier, 혹은 사용자 정의 Annotation을 사용하지 않고

Discountpolicy rateDiscountPolicy;

위와 같이 필드명(패러미터명)을 바꿔서 사용하는 방식이 일반적인지 여쭤보고 싶습니다. 강의에서는 위와 같은 방식을 별로 강조하지 않으셔서, 의문점이 남습니다. 또한 제가 생각하기에도 바람직한 방법은 아닌 것 같은게,

 

package hello.core.order;

import hello.core.discount.DiscountPolicy;
import hello.core.member.Member;
import hello.core.member.MemberRepository;
import hello.core.member.MemoryMemberRepository;
import lombok.RequiredArgsConstructor;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

@Component
@RequiredArgsConstructor
public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository;
    private final DiscountPolicy rateDiscountPolicy;

    @Override
    public Order createOrder(Long memberId, String itemName, int itemPrice) {
        Member member = memberRepository.findById(memberId);
        int discountPrice = rateDiscountPolicy.discount(member, itemPrice);

        return new Order(memberId, itemName, itemPrice, discountPrice);
    }
}

위와 같이 rateDiscountPolicy를 필드명으로 선언하면 createOrder에서도 rateDiscountPolicy로 사용해야 하는 불상사가 일어나지 않나요?

긴 글 읽어봐주셔서 감사합니다.

spring 객체지향

답변 2

3

김영한

안녕하세요. 민설님

개발은 기본적으로 명확한 것이 더 중요합니다.

그래서 필드명을 기반으로 무언가를 매칭하는 것은 저도 좋은 방법이라 생각하지 않습니다.

차라리 이런 경우 명확하게 @Qualifier를 사용하는 것이 더 나은 방법이라 생각합니다.

롬복의 설정을 변경하는 것은 @Qualifier를 좀 더 편하게 사용하는 방법이기 때문에, 이 경우 팀의 합의가 있다면 가능하다 생각합니다. 물론 이 경우 해당 설정을 하는 것이 부담된다면 @RequriedArgsConstructor를 사용하지 않는 것도 방법입니다.

사실 이런 결정은 @RequriedArgsConstructor를 자주 사용한다는 가정하에 추가로 @Qualifier를 매우 자주 사용해야 하는 상황에서는 팀원들의 공감을 얻기 쉬울거에요.

그런데 @RequriedArgsConstructor를 자주 사용한다는 가정하에 추가로 @Qualifier를 사용하는 상황이 매우 적다면 해당 설정을 변경하기 보다는 해당 부분에는 @RequriedArgsConstructor를 사용하지 않는 것이 더 나은 방법이라 생각합니다. 공감을 얻기도 어렵구요.

감사합니다.

1

인프런 AI 인턴

안녕하세요, 인프런 AI 인턴입니다.

실무에서 Lombok의 RequiredArgsConstructor를 사용하는 경우, 보통은 Primary, Qualifier, 혹은 사용자 정의 Annotation을 필드 앞에 적는 방식을 많이 사용합니다. 이는 개발 팀 전체의 Lombok 설정이 바뀌는 것이지만, 보통 합의하여 사용하는 경우가 많습니다.

필드명(패러미터명)을 바꿔서 사용하는 방식도 일반적으로 사용하는 방식 중 하나입니다. 하지만 이 방식은 가독성이 좋지 않는 단점이 있고, 예를 들어서 변수명을 오타로 작성할 경우에는 컴파일 시점에 바로 알아챌 수 없어서 디버깅이 까다로워질 수 있습니다.

따라서, 필드명(패러미터명)을 바꿔서 사용하는 방식 보다는 필드 앞에 Annotation을 적어서 사용하는 것이 가독성과 유지보수 측면에서 더 바람직합니다.

마지막으로, rateDiscountPolicy를 필드명으로 선언하는 것은 위험한 방식이 될 수 있습니다. 필드명과 메서드 파라미터명이 다른 경우, 개발자가 실수로 다른 변수를 사용할 가능성이 있기 때문입니다. 이를 방지하려면, 해당 인스턴스를 final로 만들고 생성자 파라미터명과 필드명을 동일하게 작성하면 됩니다.

감사합니다.

코드 자료

0

32

2

구현체가 동적으로 정해질 때, 팩토리 기법을 사용하나요?

0

52

2

MemberService의 인터페이스를 왜 사용하는지 궁금합니다.

0

75

1

롬복 @Setter를 써야 하는 상황이 있는건가요?

0

89

1

빈 등록 메서드의 파라미터가 빈이 아니어도 되나요?

0

81

1

테스트 속도가 나중에 영향이 있을까요?

0

77

1

gradle 설정 안떠서 질문 남깁니다!

0

121

2

build.gradle로 프로젝트를 여는 이유

0

85

1

provider 사용하는 이유

0

89

1

다음 강의 뭘 들어야 할까요

0

126

2

프로토타입 빈, 직접 destroy 호출 안 할 경우

0

64

1

beanB

0

82

2

퀴즈다시풀기

0

67

1

Gradle로 바꿔도 오류가 똑같이 발생하네요 ㅠㅠ

0

92

2

"중복 등록과 충돌" 강의에서 강사님과 다른 에러가 발생합니다.

0

67

3

run 실행했는데 결과창이 이렇게 뜨네요 왜 그런건가요>

0

106

2

도메인의 정의?

0

59

1

ApplicationContext 질문입니다.

0

63

1

@Scope의 proxyMode를 사용할때 단위 테스트 방법

0

88

2

ai api 선정하기 관련 질문

0

118

2

생성자 자동주입 관련해서

0

65

1

생성자 직접 호출 vs 팩토리 메서드 패턴

0

96

2

Spring에서 SessionScope와 RequestScope는 함께 사용되나요?

1

65

1

12:25

0

77

2