Spring 29. 빌더 패턴

프로젝트를 진행하다가 수많은 Response Dto 클래스의 양을 보고 뭔가 잘못됨을 느꼈고, Dto의 양을 줄이려고 한 Dto에 근 5개의 생성자를 쑤셔 넣다가 알게된 패턴이다.

일단 내가 이해한 빌더 패턴은 다음과 같다.
생성자로 필드에 값을 저장하던걸 Builder 클래스를 만들어서 대체하는 것.

이를 통해서 생성자 인자 순서를 파악하지 않아도 되고, 수많은 생성자 열거를 안해도 되고, 잘못된 값을 넣는 실수도 안할 수 있게 된다.

우선 Entity가 다음과 같다고 가정하자

@Getter
@Setter
@NoArgsConstructor
public class Event  {

    private String title;

	private String content1;
    private String content2;
    private String content3;
    private String content4;
    private String content5;
    private String content6;
}

Builder가 적용될 수 있는 Dto는 Response가 적합하므로 Response를 보면 다음과 같다.

@Getter
@Setter
@AllArgsConstructor
public class EventResponseDto {

    private String title;
    
    private String content1;
    private String content2;
    private String content3;
    private String content4;
    private String content5;
    private String content6;
}

여기도 사실 뭐 다른건 없는데, 지금까지 나는 응답을 할 때 {title, content1},{title, content3}, {title, content4, content6} 이런 경우 Dto를 3개를 만들어서 반환했다. 그러다가 뭔가 이상함을 느끼고 하나의 Dto로 통합한 후 생성자를 여러개 만들었는데, Builder를 사용하면 AllArgsConstructor 하나만 있으면 된다.

빌더는 다음과 같다.

package com.example.demo;

public class EventBuilder {

    private String title;
    private String content1;
    private String content2;
    private String content3;
    private String content4;
    private String content5;
    private String content6;

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

    public EventBuilder content2(String content2){
        this.content2 = content2;
        return this;
    }

    public EventBuilder content3(String content3){
        this.content3 = content3;
        return this;
    }

    public EventBuilder content4(String content4){
        this.content4 = content4;
        return this;
    }

    public EventBuilder content5(String content5){
        this.content5 = content5;
        return this;
    }

    public EventBuilder content6(String content6){
        this.content6 = content6;
        return this;
    }


    public EventResponseDto build() {
        return new EventResponseDto(title, content1, content2, content3, content4, content5, content6);
    }
}

보면 Builder에서 각 필드 명을 생성자로 만들어서 단일 값만 받고, build메소드로 전체를 받은 객체를 넘겨주고 있다.

    public EventResponseDto createEvent(EventRequestDto eventRequestDto) {
        EventResponseDto eventResponseDto = new EventBuilder()
                .title(eventRequestDto.getTitle())
                .content2(eventRequestDto.getContent2())
                .content6(eventRequestDto.getContent6())
                .build();

        return eventResponseDto;
    }

Service에선 이렇게 처리를 하는데, 각 대상 필드만 연속적으로 받고, Build를 딸깍해주면 된다.

그러면 이렇게 반환이 된다.

이렇게 Builder를 쓰면 객체 생성 과정이 일관된 프로세스로 변하고, 필수 멤버와 선택적 멤버를 분리할 수 있다.

내가 빌더 패턴을 찾는 이유는 바로 필수 - 선택 멤버 분리에 있는데, 빌더 패턴도 단점은 좀 있다. 일단 생성자보다 낮은 성능이 있다. 하지만 이미 자바를 사용한다는것부터 성능을 포기한거긴 하지만, 그 중에서도 어느정도의 성능을 챙기기 위해선 생성자를 사용하는게 좋을 수 있다.

빌더 패턴에는 2가지 종류가 있는데 이건 추후..