혼자 스프링을 공부하다 보니 @Setter를 사용할 때도 있고 @Builder를 사용하는 경우도 있었다.

나는 주로 @Setter를 사용했지만, 문득 @Builder와 @Setter의 차이점이 궁금해졌다. 기능이 비슷해 보였기 때문이다.

조금 찾아보니, @Setter는 지양하고 @Builder를 사용하는 것이 더 좋은 선택이라는 의견이 많았다.

일단 @Setter 의 단점을 알아보자.

@Setter

객체의 일관성 저하

• @Setter를 사용하면 객체의 상태를 언제든지 변경할 수 있어 객체의 일관성을 유지하기 어렵다.

• 객체지향 원칙 중 OCP(Open-Closed Principle)를 위반할 수 있다.

  • @Setter는 객체의 상태 변경에 대해 너무 개방적이기 때문이다.

의도의 불명확성

• @Setter를 사용하면 객체의 상태 변경 의도가 불분명해진다.코드만 봤을 때 생성인지 수정인지 구분하기 어려울 수 있다.
• 예를 들어, setName() 메서드만으로는 이것이 객체 생성 시 이름을 설정하는 것인지, 기존 이름을 수정하는 것인지 파악하기 어렵다.

불필요한 변경 가능성

• @Setter를 사용하면 모든 필드에 대해 변경 메서드가 생성되어, 변경되면 안 되는 중요한 값도 변경 가능한 것으로 오해할 수 있다. -> 이는 잠재적으로 버그를 유발할 수 있는 위험 유발

가독성 저하

• 많은 @Setter 메서드가 있으면 코드의 가독성이 떨어질 수 있다.
• 특히 여러 필드를 설정해야 하는 경우 코드가 장황해질 수 있다.

@Builder

객체 생성의 유연성과 명확성

• @Builder를 사용하면 복잡한 객체를 단계별로 생성할 수 있어 유연성이 높아진다.
• 선택적 매개변수가 많은 객체를 다룰 때 특히 유용
• 객체 생성의 의도가 명확해져, 코드만 봐도 객체를 생성하는 것인지 쉽게 파악 가능

가독성 향상

• 메서드 체이닝을 통해 코드의 가독성과 표현력이 크게 향상
• 객체 생성 과정이 더 자연스럽고 이해하기 쉬워짐
• 여러 필드를 설정해야 하는 경우에도 코드가 간결하고 명확해짐

불변성 지원과 일관성 유지

• 불변 객체 생성을 용이하게 하여 스레드 안전성을 높인다.
• 객체의 일관된 상태를 유지하는 데 도움이 된다.
• 객체 생성 시점에 모든 값을 설정하므로, 객체의 일관성을 유지하기 쉽다.

캡슐화 강화

• 객체 생성 세부 사항을 빌더 클래스 내에 캡슐화하여 관심사를 분리
• 변경되면 안 되는 중요한 값들을 보호할 수 있어, 잠재적인 버그 발생 가능성을 줄인다.

OCP 준수

• @Builder를 사용하면 객체 생성 후 상태 변경을 제한할 수 있어 OCP(Open-Closed Principle)를 더 잘 준수 가능

텔레스코핑 생성자 문제 해결

• 많은 매개변수를 가진 생성자의 문제(텔레스코핑 생성자 안티패턴)를 해결
• 필수 필드와 선택적 필드를 명확히 구분할 수 있어, 객체 생성 시 필요한 값만 설정할 수 있다.

결론

1. 객체의 일관성과 불변성: @Builder를 사용하면 객체 생성 시점에 모든 값을 설정하므로, 객체의 일관성을 유지하고 불변성을 보장하기 쉽다.

2. 코드 가독성: 메서드 체이닝을 통해 객체 생성 코드가 더 간결하고 이해하기 쉬워진다.

3. 유연성: 복잡한 객체 생성이나 선택적 매개변수가 많은 경우에 특히 유용

4. 의도의 명확성: 객체 생성의 의도가 명확해져, 코드의 목적을 쉽게 파악할 수 있다.

5. OCP 준수: 객체 생성 후 상태 변경을 제한할 수 있어 객체 지향 원칙을 더 잘 지킬 수 있.

권장

• 복잡한 객체 생성이나 불변 객체를 만들 때는 @Builder를 사용하는 것이 좋다.
• 단순한 DTO나 자주 변경이 필요한 객체의 경우에만 제한적으로 @Setter를 사용하는 것이 좋다.
• 객체의 일관성과 안정성이 중요한 경우에는 @Builder를 우선적으로 고려해야 한다.

참고
tlskals1의 티스토리 블로그
망나니개발자의 블로그