[Gof의 디자인패턴] 빌더 패턴

🐙 빌더 패턴이란?

- 다양한 구성의 인스턴스들을 동일한 과정을 거쳐 생성할 수 있도록 하는 패턴

 

🐙 빌더 패턴의 필요성?

- 복잡한 객체를 생성하는 클래스와 표현하는 클래스를 분리해서 동일한 절차에서도 서로 다른 표현을 생성하는 방법을 제공

- 생성해야 하는 객체가 optional 한 속성을 많이 가질 때 더 좋음

- 필요없는 파라미터들에 대해서 일일이 null 값을 넘기지 않아도 됨

- Optional 한 인자가 많아지면 타입과 순서에 대한 관리가 어려운데 이를 해결해줌

 

🐙 빌더 패턴 구현하기

public class Lecture {

    String startTime;

    String endTime;

    String day;

    String professorName;

    String title;

    String content;

    String bookName;

    String classRoom;}

도메인은 위와 같다. 만일 강의에 책이 필요하지 않거나, 온라인 수업이라서 classRoom 이 존재하지 않는다면 해당 값들은 모두 null이 되어야 한다. 따라서 점층적인 생성자 패턴을 이용해 요구사항을 만족시킬 수도 있다.

 

점층적인 생성자 패턴

- 오버로딩을 통해서 생성자를 여러개 만드는 것

public Lecture(String startTime, 
                   String endTime, 
                   String day, 
                   String professorName,
                   String title, 
                   String content
    ) {
        this.startTime = startTime;
        this.endTime = endTime;
        this.day = day;
        this.professorName = professorName;
        this.title = title;
        this.content = content;
    }
    

    public Lecture(String startTime,
                   String endTime, 
                   String day, 
                   String professorName, 
                   String title, 
                   String content,
                   String bookName, 
                   String classRoom) {
        this.startTime = startTime;
        this.endTime = endTime;
        this.day = day;
        this.professorName = professorName;
        this.title = title;
        this.content = content;
        this.bookName = bookName;
        this.classRoom = classRoom;
    }

위와 같이 Optional 한 파라미터들을 해결할 수 있다. 그러나, 이와 같이 생성자를 정의하게 된다면 매번 새로운 생성자를 만들거나 null 값을 일일이 넘겨줘야 하는 문제가 있다. 또한 추후 코드를 볼 때 어떤 필드에 값을 넣었는지 한눈에 알아보기 어렵다. 그렇다면 일일이 모두 setter 를 이용하면 되지 않을까?

 

자바 빈 패턴

Lecture lecture = new Lecture();
lecture.setTitle("한국 문학사");
lecture.setContent("한국 문학사에 대해서 온라인으로 배웁니다.");
lecture.setBookName("한국 문학사 II");
lecture.setProfessorName("김철수");

이는 일일이 Null 을 넘겨주지 않아도 되고, 선택적으로 파라미터를 넘겨줄 수 있기에 어느 정도의 문제는 해결됐다.

그러나, 함수 호출이 파라미터의 개수만큼 이루어지고 한번으로 생성할 수 없다.

또한, immutable 하지 않기 때문에 일관성이 깨질 우려가 존재한다. 

 

 

빌더 패턴

public interface LectureBuilder {

    LectureBuilder startTime(String statTime);

    LectureBuilder endTime(String endTime);

    LectureBuilder day(String day);

    LectureBuilder professorName(String professorName);

    LectureBuilder title(String title);

    LectureBuilder content(String content);

    LectureBuilder bookName(String bookName);

    LectureBuilder classRoom(String classRoom);

    Lecture getInstance();

}

위의 다이어그램에서 Builder 에 해당하는 인터페이스를 정의한다. 이는 객체를 생성하기 위한 step 을 정의하는 것이다. 

따라서 모든 메서드들의 반환 타입이 builder 인 것이다. builder 을 반환하여 계속해서 파라미터의 값을 받는 것이다.

 

public class DefaultLectureBuilder implements LectureBuilder{

    String startTime;

    String endTime;

    String day;

    String professorName;

    String title;

    String content;

    String bookName;

    String classRoom;

    @Override
    public LectureBuilder startTime(String statTime) {
        this.startTime = statTime;
        return this;
    }

    @Override
    public LectureBuilder endTime(String endTime) {
        this.endTime = endTime;
        return this;
    }

    @Override
    public LectureBuilder day(String day) {
        this.day = day;
        return this;
    }

    @Override
    public LectureBuilder professorName(String professorName) {
        this.professorName = professorName;
        return this;
    }

    @Override
    public LectureBuilder title(String title) {
        this.title = title;
        return this;
    }

    @Override
    public LectureBuilder content(String content) {
        this.content = content;
        return this;
    }

    @Override
    public LectureBuilder bookName(String bookName) {
        this.bookName = bookName;
        return this;
    }

    @Override
    public LectureBuilder classRoom(String classRoom) {
        this.classRoom = classRoom;
        return this;
    }

    @Override
    public Lecture getInstance() {
        return new Lecture(startTime, endTime, day, professorName, title, content, bookName, classRoom
        );
    }
}

위의 다이어그램에서 ConcreteBuilder 에 해당한다. 

이를 바탕으로 객체를 생성해보자.

 

Lecture first = new DefaultLectureBuilder().title("한국 문학사의 이해")
        .bookName("한국 문학사 II")
        .content("한국의 문학사에 대해서 온라인으로 배웁니다.")
        .professorName("김철수")
        .day("수")
        .startTime("13")
        .endTime("15")
        .getInstance();

위와 같이 객체를 생성해주면 된다. . 을 이용하여 계속 이을 수 있는 이유는 모든 인자들의 반환값이 builder 이기 때문이다.

마지막에는 getInstance 메서드를 호출하여 객체를 생성한다.

 

위의 다이어그램에 해당하는 Director 를 이용하면 클라이언트 코드를 줄일 수 있다.

 

public class LectureDirector{

    private LectureBuilder lectureBuilder;

    public LectureDirector(LectureBuilder lectureBuilder){
        this.lectureBuilder = lectureBuilder;
    }

    public Lecture communicativeEnglish(){
        return lectureBuilder.professorName("김미영")
                .startTime("13")
                .endTime("15")
                .bookName("Communicative English part I")
                .title("교양 영어")
                .content("필수 교양 영어 수업입니다.")
                .getInstance();
    }

}

LectureDirector lectureDirector = new LectureDirector(new DefaultLectureBuilder());
Lecture newLecture = lectureDirector.communicativeEnglish();

 

🐙 빌더 패턴에서 필수로 입력받아야 하는 파라미터 지정하기

public DefaultLectureBuilder(String startTime, 
                             String endTime,
                             String professorName){
    this.startTime = startTime;
    this.endTime = endTime;
    this.professorName = professorName;
}

 

필수로 입력받아야 하는 파라미터들은 빌더의 생성자에 미리 넣어둔다. 이후 선택적으로 입력받는 파라미터들에 대해서만 빌더 패턴을 적용한다. 이는 위와 동일하니 생략하겠다.

 

🐙 빌더 패턴의 장점/단점

장점

- 가독성이 좋다

- 객체의 일관성을 깨지 않을 수 있다

- 유연성을 확보할 수 있다

- 불변성을 확보할 수 있다

- 순차적인 단계를 강제할 수 있다.

//1
LectureBuilder title(String title);

//2
SecondLectureBuilder title(String title);

 

1번이 아닌 2번처럼 새로운 빌더를 반환값으로 지정하게 되면 해당 빌더에 존재하는 메서드를 사용하도록 강제할 수 있다.

즉, 객체의 title 을 지정하고 나서는 다른 빌더로 넘어가도록 하는 것이다.

 

단점

- 인스턴스를 만들어서 사용해야 한다

- 디렉토리 구조가 복잡해질 수 있다.

 

🐙 스프링에서의 빌더 패턴

@Builder

@Builder
public class BuildMe {

    private String username;
    private int age;

}

위와 같이 Builder 어노테이션을 붙이면 아래와 같이 컴파일 시에 어노테이션이 바이트코드를 바꿔준다.

public class BuildMe {
    private String username;
    private int age;

    BuildMe(String username, int age) {
        this.username = username;
        this.age = age;
    }

    public static BuildMe.BuildMeBuilder builder() {
        return new BuildMe.BuildMeBuilder();
    }

    public static class BuildMeBuilder {
        private String username;
        private int age;

        BuildMeBuilder() {
        }

        public BuildMe.BuildMeBuilder username(String username) {
            this.username = username;
            return this;
        }

        public BuildMe.BuildMeBuilder age(int age) {
            this.age = age;
            return this;
        public BuildMe build() {
            return new BuildMe(this.username, this.age);
        }

        public String toString() {
            return "BuildMe.BuildMeBuilder(username=" + this.username + ", age=" + this.age + ")";
        }
    }
}

 

 

🐙 참고

https://dev-youngjun.tistory.com/197

빌더 패턴(Builder Pattern)

https://velog.io/@park2348190/Lombok-Builder%EC%9D%98-%EB%8F%99%EC%9E%91-%EC%9B%90%EB%A6%AC

Lombok @Builder의 동작 원리