[Solitour] Builder 패턴을 써야할까?

이 글은 Solitour 프로젝트를 진행하면서 내가 느낀 의문점과 공부했던 내용을 공유하기 위해 작성한 것이다.

 

Solitour 프로젝트에서 나는 백엔드 개발을 담당했고, 같은 역할을 맡은 동료와 함께 협업하였다.

 

프로젝트를 진행하는 중 동료 개발자의 코드를 살펴보는데, Entity 클래스와 DTO 클래스에 @Builder라는 어노테이션이 사용된 것을 발견했다.

’이게 뭐지?’라는 생각이 들었고, 곧바로 “Builder 패턴”에 대해 알아보기 시작했다.

 

 

Builder 패턴이란?

 

Builder 패턴은 객체를 생성하는 다양한 방법 중 하나로, 생성 과정에서 필요한 필드들을 유연하게 주입할 수 있는 방식을 제공한다. 이 패턴은 복잡한 객체를 간편하게 생성하고, 가독성을 높이는 장점이 있다.

 

객체 생성 방식에는 어떤 것들이 있을까?

 

객체를 생성할 때 사용하는 방식에는 크게 세 가지가 있다:

 

• 생성자 패턴: 필수 값들을 생성자를 통해 전달받아 객체를 생성하는 방식.

• Setter 주입: 객체를 생성한 후 setter 메서드를 이용해 필요한 값들을 설정하는 방식.

• Builder 패턴: 유연하고 직관적인 방식으로, 필요한 값들을 선택적으로 설정한 후 객체를 생성하는 방식.

 

지금까지 나는 주로 생성자 패턴과 Setter 주입 방식을 사용해왔기 때문에, Builder 패턴에 대해 더 깊이 이해하고 싶었다.

이 글에서는 Builder 패턴에 대해 공부한 내용을 정리하고, 이 패턴을 사용하면서 느낀 점들을 설명하고자 한다.

 

 

일단 나는 Lombok을 이용해서 Builder 패턴을 사용하였다 

 

import lombok.Builder;

@Builder
public class User {
    private String name;
    private int age;
    private String email;
}

 

이렇게  클래스 선언부 위에 @Builder 붙히면 해당 클래스에 대해 Builder 패턴을 사용할 수 있다

User user = User.builder()
                .name("Fiat_lux")
                .age(26)
                .email("hihi@naver.com")
                .build();

 

객체 생성은 위와 같이 하면된다 

 

 

 

그럼 Builder 패턴을 사용하면 장점이 무엇일까?

 

1. 유연한 객체 생성 

 

필수 필드와 선택 필드를 유연하게 설정 할 수 있어서 생성자를 여러 개 만들 필요 없다.

특히 필드가 많은 경우에는 코드가 간결해지고 유지보수가 쉬워진다

 

개인적으로 이 장점이 가장 크게 와 닿았는데, 

필드가 많은 클래스에서 특히 그렇다. 필드가 많을수록 어떤 값을 어떤 순서대로 넣어줘야 할지 헷갈릴 때가 있는데, Builder 패턴을 사용하면 그런 문제에서 해방된다.

즉, 클래스 코드를 일일이 확인하지 않고도 쉽게 객체를 생성할 수 있기 때문이다.

 

 

2. 가독성 향상

 

메서드 체이닝 방식으로 객체를 생성하기 때문에, 어떤 필드에 어떤 값이 주입되는지 직관적으로 알 수 있다.

 

이 부분에서 Builder 패턴의 장점을 확실히 느낀 경험이 Solitour 프로젝트의 Gathering 엔티티에서 벌어졌다.

 

이 엔티티에는 personCount와 viewCount라는 두 필드가 있었는데, 둘 다 Integer 타입이었고, 생성자에서 나란히 정의되어 있었다.

public Gathering(... Integer personCount, Integer viewCount, ...) {
	...
    this.personCount = personCount;
    this.viewCount = viewCount;
    ...
}

이런식으로 말이다 

 

Gathering 객체를 생성할 때, 나는 이 두 값의 순서를 잘못 넣었다.

그 결과, API 응답 데이터가 계속해서 엉뚱한 값을 반환했고, 이 문제를 해결하는 데 많은 시간을 할애했다.

문제의 원인이 직관적으로 보이지 않았기 때문이다.

 

Builder 패턴을 사용했더라면 이런 실수를 방지할 수 있었을 것이다.

메서드 체이닝을 통해 각 필드에 값을 명확히 할당할 수 있었기 때문에, 실수로 값이 바뀌는 일을 미연에 방지할 수 있었을 것이다.

 

 

3. 확장성 

 

필요한 필드만 선택적으로 설정할 수 있어, 필드가 많거나 복잡한 객체를 만들 때 더욱 적합하다. Builder 패턴을 사용하면, 여러 필드가 있는 상황에서도 유연하게 객체를 생성할 수 있고, 필요한 부분만 선택적으로 수정하거나 추가하는 데도 용이하다.