🏗️ 빌더(Builder) 패턴을 사용하는 이유

평화롭게 프로젝트를 진행하던 도중에 정말 어이 없는 실수를 해서 잠깐 삽질하는 시간을 가지고 왔다.

@Data
@AllArgsConstructor
public class VoteRequest {
    private Long selectedOptionId;
    private Long memberId;

		...
}

// 문제의 코드. 파라미터의 순서를 서로 바꿔서 전달함...
VoteRequest voteRequest = new VoteRequest(**member.getId(), optionB.getId()**);

위와 같이 작성된 DTO 클래스의 인스턴스를 생성할 때 인자를 잘못 전달해서 이상한 오류가 발생했는데, 하필 둘 다 Long 타입이라 한참을 헤맸다.

이러한 실수를 다음에 또 일어나지 않도록 하고자, 어노테이션만 달아놓고 뭔지도 모르고 쓰던 Builder 패턴에 대해 학습해봤다.

빌더 패턴이란?

빌더 패턴이란 객체의 생성 과정과 표현 방법을 분리하여 다양한 구성의 인스턴스를 만드는 생성 패턴이다.

예를 들어 집을 짓는다고 할 때, 어떤 집은 목재를 사용하고 다른 집은 콘크리트를 사용할 수 있다. 이렇게 집을 짓는 과정(생성 과정)이 다르더라도 완성된 모습은 집이라는 공통적인 형태(표현 방법)를 띄게 될 것이다.

이처럼 빌더 패턴은 객체의 생성 과정과 표현 방법이라는 두 관심사를 분리하여 유지 보수를 용이하게 만든다.

빌더 패턴은 어떻게 탄생했을까?

🕑 점층적 생성자 패턴(Telescoping Constructor Pattern)

점층적 생성자 패턴은 필수 매개변수와 함께 0개부터 1개, 2개씩 점차 증가하는 선택 매개변수를 받는 형태다.
즉, 다양한 매개변수를 전달 받아 인스턴스를 생성하고 싶을 때 기존에 사용하던 생성자를 오버로딩하는 방식이다.

class Sandwich {
    // 필수
    private String bread;
    private String bacon;

    // 선택
    private String source;
    private String cheese;
    private String tomato;
    private String lettuce;

    public Sandwich(String bread, String bacon) {
        this.bread = bread;
        this.bacon = bacon;
    }

    public Sandwich(String bread, String bacon, String tomato) {
        this.bread = bread;
        this.bacon = bacon;
        this.tomato = tomato;
    }

    public Sandwich(String bread, String bacon, String source, String cheese) {
        this.bread = bread;
        this.bacon = bacon;
        this.source = source;
        this.cheese = cheese;
    }
    
    ...
}

이러한 점층적 생성자 패턴에는 몇 가지 단점이 존재한다.

1. 클래스의 필드 개수가 증가할수록 생성자에 들어갈 수 있는 인자 수가 증가하게 되는데, 이렇게 되면 생성자의 몇 번째 인자가 어떤 필드였는지 헷갈리는 문제가 발생한다.
   (내가 이번에 빌더 패턴을 학습하게 된 근본적인 원인이다…🥲)

2. 위 예제에서 샌드위치를 만들 때 빵과 토마토만 넣고 싶은 경우 아래 생성자에서 bacon 부분은 어쩔 수 없이 null을 전달해야 한다.

   public Sandwich(String bread, String bacon) {
       this.bread = bread;
   		this.bacon = bacon;
   }

3. ‘점층적 생성자’라는 이름에서 알 수 있듯, 타입이 다양할수록 생성자가 기하급수적으로 증가한다. 이는 가독성을 떨어뜨리며 유지 보수 측면에서도 굉장히 좋지 않다.

🕢 자바 빈(Java Beans) 패턴

위에서 살펴본 점층적 생성자 패턴의 단점을 보완하기 위해 고안된 패턴으로, 매개변수가 없는 생성자로 객체를 생성한 후 setter를 이용해 필드를 초기화하는 방식이다.

class Sandwich {
		...

    public Sandwich() {
    }

    public void setBread(String bread) {
        this.bread = bread;
    }

    public void setBacon(String bacon) {
        this.bacon = bacon;
    }

    // 무수한 setter들...
}

자바 빈 패턴은 점층적 생성자 패턴의 단점을 어떻게 보완했을까?

1. 생성자의 매개변수가 헷갈리는 문제 ⇒ 클래스의 각 필드마다 setter가 존재하고, 이 setter를 통해 값을 주입하기 때문에 매개변수를 헷갈릴 일이 없다.
2. null 전달 ⇒ 매개변수가 없는 생성자로 인스턴스를 먼저 생성하기 때문에 억지로 null을 전달할 필요가 없다.
3. 가독성 문제 ⇒ 많은 생성자가 필요하지 않기 때문에 가독성이 올라간다.

이처럼 setter를 사용하면 유연한 객체를 생성할 수 있지만, 자바 빈 패턴도 치명적인 단점이 존재한다.

1. 일관성(consistency)

   필수 매개변수는 객체가 초기화될 때 반드시 설정되어야 한다. 하지만 개발자가 실수로 필수 매개변수의 setter를 작성하지 않거나 호출하지 않을 경우 해당 객체의 일관성이 무너지게 된다.

   이처럼 일관성이 무너진 객체를 만약 다른 곳에서 사용하게 되면 런타임 예외가 발생할 것이다.

2. 불변(immutable)

   외부적으로 setter를 노출하게 되면, 누군가 고의로 setter를 호출해서 객체를 조작할 수 있게 된다. 즉, 객체가 언제든지 변할 수 있는 위험이 있다.

🕙 빌더(Builder) 패턴

점층적 생성자 패턴과 자바 빈 패턴의 모든 문제들을 해결하기 위해 드디어 빌더 패턴이 등장했다.

빌더 패턴은 별도의 클래스(Builder)를 만들어 메서드를 통해 값을 하나하나 전달 받고, 최종적으로 하나의 인스턴스를 생성하여 반환하는 방식이다.

빌더 패턴 구조

예제를 통해 빌더 패턴의 구조를 살펴보자.

Post 클래스

게시글을 의미하는 Post 클래스는 멤버 변수로 아이디, 제목, 내용, 작성자, 작성일을 가지고 있으며, 하나의 생성자도 존재한다.

class Post {
    private Long id; // 아이디
    private String title; // 제목
    private String content; // 내용
    private String createdBy; // 작성자
    private LocalDate createdDate; // 작성일

    public Post(Long id, String title, String content, String createdBy, LocalDate createdDate) {
        this.id = id;
        this.title = title;
        this.content = content;
        this.createdBy = createdBy;
        this.createdDate = createdDate;
    }
}

빌더 클래스 구현

다음으로 Post 클래스의 인스턴스를 생성하기 위한 빌더 클래스를 구현한다.

class PostBuilder {
    private Long id; // 아이디
    private String title; // 제목
    private String content; // 내용
    private String createdBy; // 작성자
    private LocalDate createdDate; // 작성일

    public PostBuilder id(Long id) {
        this.id = id;
        return this;
    }

    public PostBuilder title(String title) {
        this.title = title;
        return this;
    }

    public PostBuilder content(String content) {
        this.content = content;
        return this;
    }

    public PostBuilder createdBy(String createdBy) {
        this.createdBy = createdBy;
        return this;
    }

    public PostBuilder createdDate(LocalDate createdDate) {
        this.createdDate = createdDate;
        return this;
    }

    public Post build() {
        return new Post(id, title, content, createdBy, createdDate);
    }
}

PostBuilder 클래스의 멤버 변수는 대상 클래스인 Post의 멤버 변수와 똑같이 구성되어 있으며, 각 멤버 변수에 대한 초기화 메서드를 구현하고 있다.

이때 각 초기화 메서드는 가독성을 위해, 그리고 기존 setter와 차별하기 위해 메서드명을 간단하게 필드명으로 지어준다. 그리고 메서드에서 중요하게 봐야할 또 다른 점은 자기 자신을 반환한다는 것이다. 이는 후에 설명할 메서드 체이닝을 위한 과정이다.

마지막으로 최종 객체를 만들어주는 build 메서드를 구현한다. 이 메서드는 초기화한 멤버 변수들을 가지고 Post를 생성하여 반환한다.

실행 코드

이제 PostBuilder 클래스를 이용해 Post 객체를 생성해보자.

public class Main {
    public static void main(String[] args) {
        Post post = new PostBuilder()
                .id(1L)
                .title("게시글 제목")
                .content("게시글 내용")
                .createdBy("홍길동")
                .createdDate(LocalDate.now())
                .build();

        System.out.println(post);
    }
}

PostBuilder 클래스의 메서드를 호출하여 값을 전달한 뒤 최종적으로 build 메서드를 호출하면 다음과 같이 Post 객체가 생성된다.

빌더 패턴의 장단점

장점

• 객체 생성 과정을 일관된 프로세스로 표현 빌더 패턴을 사용하면 어떤 필드에 어떤 값이 설정되는지 직관적으로 알 수 있다. 따라서 객체를 일관적으로 생성할 수 있게 된다. 특히 연속된 같은 타입의 매개변수를 많이 설정해야 할 때 발생 가능한 실수를 방지할 수 있다.
  
• 디폴트 매개변수 생략 간접 지원 인자를 따로 전달하지 않을 경우 다음과 같이 기본적으로 설정되는 매개변수를 디폴트 매개변수라고 한다.

  public Post(Long id, **String title = "제목"**, String content, ...) {
      this.id = id;
      this.title = title;
  	  this.content = content;
  		...
  }

  Python, JS, C++ 등 다수 언어에서 디폴트 매개변수를 지원하지만, Java에서는 지원하지 않는다. 따라서 디폴트 매개변수를 구현하기 위해서는 클래스 필드 변수에 초깃값을 미리 설정하고, 초기화된 필드는 매개변수에서 제외시킨 생성자를 따로 만들어야 한다. 하지만 이는 결국 지나친 생성자 오버로딩으로 인해 본래의 문제로 되돌아가는 것이다.

  class PostBuilder {
      private Long id;
      private String title = "제목"; // default parameter 역할 수행
      private String content;
      private String createdBy;
      private LocalDate createdDate;
  
  		...

  빌더 패턴에서도 디폴트 매개변수를 구현하는 방법은 동일하다. 하지만 디폴트 매개변수가 설정된 필드에 대한 메서드를 호출하지 않는 방식을 사용하면, 디폴트 매개변수를 생략하고 호출하는 효과를 간접적으로 구현할 수 있다.

  Post post = new PostBuilder()
          .id(1L)
          .title("게시글 제목")
          .content("게시글 내용")
          .createdBy("홍길동")
          .createdDate(LocalDate.now())
  				.build();
  
  System.out.println(post);

  
  
• 필수 멤버와 선택 멤버 분리 가능 초기화가 필수인 멤버 변수는 빌더 클래스의 생성자로 받게 함으로써, 필수 멤버 변수를 초기화 해야만 객체가 생성되도록 유도할 수 있다.

  Post post = new PostBuilder(1L)
  				.content("게시글 내용")
          .createdBy("김철수")
          .createdDate(LocalDate.now())
  				.build();

• 멤버별 초기화 검증 가능 생성자를 사용해 값을 전달 받을 경우 매개변수에 대한 검증 로직을 각 생성자 안에서 별도로 처리해야 한다. 이는 생성자의 크기가 커지는 문제를 야기한다. 반면에 빌더 패턴을 사용하면 각각의 메서드를 통해 멤버별로 검증 로직을 따로 둘 수 있기 때문에 유지 보수가 용이해진다.
  

단점

장점만 있을 것 같은 빌더 패턴에도 몇 가지 단점이 존재한다.

• 코드 복잡성 증가 N개의 클래스에 대해 N개의 빌더 클래스를 만들어야 하기 때문에 관리해야 할 클래스 개수가 증가해지면서 구조가 복잡해진다.
  
• 성능 이슈 매번 빌더 클래스의 메서드를 호출하기 때문에 생성자보다는 성능이 약간 떨어진다. 물론 객체 생성 비용 자체가 그렇게 크지 않아 심각한 문제는 아니다.
  

앞에서 봐서 알 수 있듯이 빌더 패턴의 코드는 다소 장황하다.
따라서 필드 수가 적고 변경 가능성이 없으면 차라리 정적 팩토리 메서드를 이용하자.
다만 API는 시간이 지날수록 매개변수가 증가하기 때문에 애초에 빌더 패턴으로 시작하는게 나을 수도 있다.

빌더 클래스는 구현할 클래스의 내부 정적 클래스로 구현한다

빌더 패턴 구조 부분에서 보여준 Post 클래스는 사실 다음과 같이 구현되어야 한다.

빌더 클래스가 Post의 내부 정적 클래스로 구현되며, Post의 생성자는 private으로 설정한다.

class Post {
    private Long id; // 아이디
    private String title; // 제목
    private String content; // 내용
    private String createdBy; // 작성자
    private LocalDate createdDate; // 작성일

    private Post(Builder builder) {
        this.id = id;
        this.title = title;
        this.content = content;
        this.createdBy = createdBy;
        this.createdDate = createdDate;
    }

    public static class Builder {
        private Long id; // 아이디
        private String title; // 제목
        private String content; // 내용
        private String createdBy; // 작성자
        private LocalDate createdDate; // 작성일

        public Builder id(Long id) {
            this.id = id;
            return this;
        }

        public Builder title(String title) {
            this.title = title;
            return this;
        }

        public Builder content(String content) {
            this.content = content;
            return this;
        }

        public Builder createdBy(String createdBy) {
            this.createdBy = createdBy;
            return this;
        }

        public Builder createdDate(LocalDate createdDate) {
            this.createdDate = createdDate;
            return this;
        }

        public Post build() {
            return new Post(id, title, content, createdBy, createdDate);
        }
    }
}

하나의 빌더 클래스는 오직 하나의 대상 객체 생성만을 위해 사용된다. 따라서 두 클래스를 물리적으로 묶어버림으로써 두 클래스 간의 관계를 쉽게 파악할 수 있게 된다.

또한, 빌더 클래스를 정적 클래스로 구현함으로써 외부 클래스의 인스턴스 없이도 생성할 수 있게 된다.
만약 빌더 클래스가 일반 내부 클래스로 구현된다면, 내부 클래스(Builder) 생성 전에 외부 클래스(Post)의 인스턴스를 먼저 생성해야 하는 모순에 빠진다.

Post 클래스의 생성자를 private으로 설정한 이유는 대상 객체가 오직 빌더에 의해 초기화되기 때문이다. 즉, 생성자를 외부에 노출할 필요가 없기 때문에 생성자를 private으로 설정하는 것이다.

Lombok의 @Builder

개발자가 더욱 편하게 빌더 패턴을 사용할 수 있도록 Lombok에서는 별도의 어노테이션을 지원하는데, 그것이 바로 @Builder다. 다음과 같이 클래스에 붙여주기만 하면 내부에 빌더 클래스와 builder 메서드를 생성된다.

@Builder
class Post {
    private Long id;
    private String title;
    private String content;
    private String createdBy;
    private LocalDate createdDate;

		private Post(Builder builder) {
        this.id = id;
        this.title = title;
        this.content = content;
        this.createdBy = createdBy;
        this.createdDate = createdDate;
    }
}

끝으로

다시는 이와 같은 실수를 하지 않겠다는 의미로 빌더 패턴의 개념과 탄생 배경, 그리고 장단점까지 알아봤다.

지금까지는 단순히 어노테이션만 붙이고 어떻게 돌아가는지 몰랐는데, 이렇게 알아보니 어떻게 사용해야할지 더 명확하게 와닿은 듯 하다.