• 카테고리

    질문 & 답변
  • 세부 분야

    백엔드

  • 해결 여부

    미해결

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

23.05.17 14:43 작성 23.05.17 14:59 수정 조회수 341

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로 사용해야 하는 불상사가 일어나지 않나요?

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

답변 2

·

답변을 작성해보세요.

3

안녕하세요. 민설님

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

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

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

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

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

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

감사합니다.

1

인프런 AI 인턴님의 프로필

인프런 AI 인턴

2023.05.18

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

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

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

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

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

감사합니다.