Think Deeply

@RequireArgsConstructor와 직접 생성자 만들기의 차이점과 고민

S_N_Y 2024. 1. 29. 21:21

controller를 만드는 와중에 필드에서 생성자를 만들어달라는 빨간 줄이 떠서 직접 생성자를 넣을 지 annotation을 쓸지 고민이 됐다. 지금같이 파라미터값으로 몇 개밖에 넣지 않는다면 생성자를 만드는 게 눈으로 어떤 파라미터가 들어가는지 알 수 있어서 보기에 좋지만 더더욱 많이 들어간다면 가독성도 좋지 않을 뿐더러 @RequireArgsConstructor와 직접 생성자를 만드는 게 어떤 차이점이 있는지 궁금해졌다.

----------------------------------------------------------------------------------------------------------------

 

1. @RequireArgsConstructor 넣기

@RequireArgsConstructor를 쓰면 빠르고 편리하게 개발할 수 있다. 그냥 이렇게 편하게 넣어도 되는 건가? 의문이 들었고 생각 없이 넣을 수도 있는데 공부하는 와중에 디테일한 부분을 집고 넘어가는게 좋을 것 같아 글을 적어본다

 

2. 직접 생성자 만들기

alt + ins해서 constructor 만들면 되긴 하는데 refactoring할 때 field값을 추가해 생성자 파라미터값을 달리할 때마다 생성자 바꿔줘야 해서 귀찮긴 한다.

 

전에 만들어놨던 코드들과 통일성을 위해 계속 생성자를 아래와 같은 식으로 만드는 경우도 있는데 뭐가 더 효율적이고 보기 좋은 코드일까?

이것저것 물어보고 찾아본 결과, 어느 것이 나은 방법이고는 없는 성향 차이이지만 kotlin으로 spring boot를 쓸 경우, @RequireArgsConstructor나 직접 생성자를 만들지도 않는다. 직관적으로 볼 때에 @RequireArgsConstructor를 넣는 것도 나쁘지 않은 것 같다.

 

그러면 @RequireArgsConstructor가 간결하니 다 이걸 붙이면 되는건가? -> 아니다

@RequireArgsConstructor을 쓸 때 모호성으로 인해 붙여주는 @Qualifier로 A,B,C를 구분했을 경우, 이 생성자가 어디에 해당하는 생성자인지 구분하기 힘들어 에러가 나는 경우가 종종 있다. 

(생성자에 인자를 표시할때, @Quailfier어노테이션을 인자에 표시해주지 않는다)

@RequiredArgsConstructor
public class WantQuailfierAutowired{

    @Qualifier("myTarget")
    private final Target taget;
    
    public WantQuailfierAutowired(Target target){ // 이건 별개로 @Qualifier 필요
        this.target = target;
    }
}

결론은 필요한 경우에만 직접 생성자를 만들어주고 아닌 경우에는 @RequireArgsConstructor를 써봐야겠다

나중에 더 복잡한 로직을 짜거나 현업에서 부딪혀봐야 판단 가능할듯하다. 일단 이렇게 하는걸로!

'Think Deeply' 카테고리의 다른 글

gradle, 왜 쓰는가  (0) 2024.02.01
static을 깊게 이해해보자  (1) 2024.01.13