들어가기 앞서
요즘 서비스 로직을 열심히 짜고 있기 때문에 배운 걸 적는 것보다는 문제를 어떻게 해결했는 지에 대해서 작성해보려고 한다.
오늘도 깨달음을 얻은 부분이 있다. 시작!
회고
정적 팩토리 메서드와 함께 사용하는 Builder ~
우리 조는 코드 컨벤션으로 생성자를 생성할 때, builder 패턴을 사용하지 않기로 했다.
저번 TIL에서 적었던 부분 같은데 다시 적으면서 상기하려고 한다. 이유는 멘토님이 현업에서는 빌더를 잘 사용하지 않는다고 하셨다. 실무에서 새로 들어오는 신입 개발자들이 빌더가 public 으로 풀려있을 경우, 무분별하게 객체가 생성될 수 있다고 하셨다. 그래서 우리도 빌더를 사용하지 않기로 했다.
그럼 본론으로 들어가서, 왜 함께 사용했는 지에 대해 먼저 설명하고자 한다.
정적 팩토리 메서드는 파라미터가 많아지면, 가독성이 떨어진다.
객체 생성 방식을 정적 팩토리 메서드로 진행할 경우, 파라미터가 많으면 하나씩 모든 값을 넣어주어야 한다. 이 부분부터 너무 힘겨운 일이다. 아래 사진으로 확인해보자.
파라미터를 보면 장난 아니다. 이렇게 수많은 파라미터를 핸들링 하면서 정적 팩토리 메서드를 사용하면, 장점보다는 단점이 부각되는 느낌을 많이 받게 되었다.
예를 들어, 생성자 방식은 파라미터의 순서대로 인자를 넣어주어야 하는데, 순서가 달라지면 휴먼 에러가 발생할 여지가 다분하다. 근데 위 사진을 보면, 생성자 방식과 똑같은 경우가 나타나는 것이다.
그래서 빌더를 적용하기로 했다.
물론, 빌더도 값을 넣어주지 않으면 null 처리가 되긴 하지만, 가독성에 중점을 두게 되었다.
private한 Builder 적용
@Builer의 옵션을 걸어주면 된다. (access = "AccessLevel.PRIVATE")
처음 고민했을 때는 Delombok 해서 private 으로 접근제어자를 변경해주는 방법을 사용했는데, 하나씩 수정하는 것이 불필요하다고 생각해 구글링해보니 해당 어노테이션이 존재하는 것을 알게 되었다.
아까 사진과는 다른 부분이지만, 아래 사진으로 확인해보자.
가독성이 향상된 것을 알 수 있다. Builder를 통해 객체를 생성하지 않는 것에 대해서는 동의를 할 수 있을 것 같다. 하지만, 정적 팩토리 메서드의 파라미터 값이 많아졌을 경우에는 어떻게 처리할 지 고민에 놓여있는 것 같다.
멘토님에게 질문을 드려 해결해야 할 것 같다.
