Oh !! Stop using @Builder라는 글을 읽고...

글 요약

1. Lombok이나 Ide 덕분에 getter setter같은 보일러플레이트 코드가 대폭 감소
2. 근데 우리가 Lombok의 @Builder를 꼭 써야해? -> No, 안티패턴으로 쓰일 때도 많음
3. 예시(롬복으로 만든 빌더는 아래와 관련된 설정을 해줄 수 없다)
   1. 빌더는 setter가 있으면 안돼 == immutable해야돼
   2. Optional이 있으면 안돼. 만약 멤버 변수가 mandatory가 아니라면 contructor가 default값을 제공해주어야..

대안

그런 부분에 있어서 롬복의 @Builder는 좋은 대안이 아니지. 라고 하면서 2가지 대안을 제시한다.
예제코드들은 본문을 참고해주세요 ㅎㅎ

대안 1 - Builder 생성자에서 mandatory값들을 지정하게 한다.

장 : mandatory값들에 대해 final로 선언해주고 빌더 생성자로 설정하게 한다. -> mandatory가 불변하고 반드시 설정되게끔 한다.
단 : 빌더 생성자까진 괜찮은데 나머지 변수들에 대한 빌더는 직접 코드를 써야돼서 귀찮을 것 같다.

대안 2 - Accessors(chanin = true)를 쓴다.

장 : 신기하다(?)... 잘 모르겠다.
단 : 롬복의 experimental 패키지에 들어있다. -> 야 이런 걸 왜써?! 빌더나 써!!
    setter에 대한 편견? 때문에 setter가 객체를 돌려주는 줄 모르고 그냥 setter 남발하는 기존코드 처럼 쓸듯.

나의 생각

몇달 전에 테스트 코드를 짜면서 어떤 변수들은 mandatory라는 걸 몰라가지고 테스트코드를 계~속 실행시키면서 A cannot be null!, B cannot be null!, C ...를 반복적으로 마주친 기억이 있다. 새삼 그때는 아 주석으로 mandatory라고 좀 써주지;;라고만 생각했는데, 지금 생각해보면 애초에 코드 입력하면서 mandatory라고 인지하게 해주는 게 훨씬 좋은 것 같다.

그런 측면에서 대안1의 방식을 쓰는 게 어떨까 싶다. 물론 써야할 코드는 늘어나지만, 롬복@Builder의 약점을 보완하면서 Builder의 장점을 챙길 수 있는 좋은 방식이라고 생각된다.

 

 

https://medium.com/gitrebase/oh-stop-using-builder-9061a5911d8c

Oh !! Stop using @Builder