[Java] 빌더 패턴(Builder Pattern)에 대해

1. 빌더 패턴(Builder Pattern)이란?

빌더 패턴은 복잡한 객체를 생성하는 방법을 정의하는 클래스와 표현하는 방법을 정의하는 클래스를 별도로 분리하여, 서로 다른 표현이라도 이를 생성할 수 있는 동일한 절차를 제공하는 패턴이다. 빌더 패턴은 생성해야 되는 객체가 Optional한 속성을 많이 가질 때 빛을 발휘한다.

 

 

 

2. 빌더 패턴(Builder Pattern)을 사용해야 하는 이유

생성자와 수정자로 구현된 다음과 같은 Employee 클래스를 바탕으로 왜 생성자나 수정자보다 빌더를 써야하는지 이해해보도록 하자.

@NoArgsConstructor
@AllArgsConstructor
public class Employee {
    private String id;
    private String name;
    private int age;
}

 

 

빌더 패턴의 장점은 다음과 같다.

(1) 필요한 데이터만 설정할 수 잇다.

(2) 유연성을 확보할 수 있다.

(3) 가독성을 높일 수 있다.

(4) 변경 가능성을 최소화할 수 있다.

 

 

 

(1) 필요한 데이터만 설정할 수 있다.

예를 들어 Employee 객체를 생성해야 하는데 age라는 파라미터가 필요 없는 상황이라고 가정하자.

생성자나 정적 메소드를 이용하는 경우라면 우리는 age에 더미 값을 넣어주거나 age가 없는 생성자를 새로 만들어주어야 한다.

// 1. 더미값을 넣어주는 방법
Employee employee = new Employee("E01", "박범성", 0)

// 2. 생성자 또는 정적 메소드를 추가하는 방법
@NoArgsConstructor 
@AllArgsConstructor 
public class Employee { 
    private String id;
    private String name;
    private int age;

    public Employee (String id, String name) {
        this.id = id;
        this.name = name;
    }
    
    public static Employee of(String id, int name) {
        return new Employee(id, name, 0);
    }
    
}

 

 

이러한 작업이 한 두번이면 번거로워도 작업을 해줄 수 있으나, 언제나 요구사항은 계속 변하게 되어있고, 반복적인 변경을 필요로 하면서 시간 낭비로 이어지게 된다. 하지만 빌더를 이용하면 동적으로 이를 처리할 수 있다.

Employee employee = Employee.builder()
             .id("E01")
             .name("박범성").build();

 

그리고 이렇게 필요한 데이터만 설정할 수 있는 빌더의 장점은 생성자 또는 정적 메소드와 비교하여 테스트용 객체를 생성할 때 용이하게 해주고, 불필요한 코드의 양을 줄이는 등의 이점을 가질수 있다.

 

 

 

 

(2) 유연성을 확보할 수 있음

예를 들어 Employee 클래스에 연락처를 나타내는 새로운 변수 tel를 추가해야 한다고 하자. 하지만 이미 다음과 같이 생성자로 객체를 만드는 코드가 있다고 하자.

// AS IS
Employee employee = new Employee("E01", "박범성", 28)

// TO BE
Employee employee = new Employee("E01", "박범성", 28, "01000010001")

 

 

그러면 우리는 새롭게 추가되는 변수 때문에 기존의 코드를 수정해야 하는 상황에 직면하게 된다. 기존에 작성된 코드의 양이 방대하다면 감당하기 어려울 수 있다.

 하지만 빌더 패턴을 이용하면 새로운 변수가 추가되는 등의 상황이 생겨도 기존의 코드에 영향을 주지 않을 수 있다.

@Test
public void 1번테스트() {
 
    // 수정 필요함 (AS IS)
    Employee employee = new Employee("E01", "박범성", 28);
    
    // 수정 필요함 (TO BE)
    Employee employee = new Employee("E01", "박범성", 28, "01000010001");

    ...

}

... 

@Test
public void 100번테스트() {

    // 수정 필요함 (AS IS)
    Employee employee = new Employee("E01", "박범성", 28);
    
    // 수정 필요함 (TO BE)
    Employee employee = new Employee("E01", "박범성", 28, "01000010001");

    ...

}

 

만약 위와 같이 Employee 객체를 생성하는 코드가 100개 있다면 모든 로직을 수정해주거나 생성자를 따로 추가하는 등의 불필요한 조치를 해주어야 할 것이다.

 하지만 빌더 패턴를 기반으로 코드가 작성되어 있다면 기존의 코드는 수정할 필요가 없다. 왜냐하면 빌더 패턴은 유연하게 객체의 값을 설정할 수 있도록 도와주기 때문이다.

 

 

 

 

(3) 가독성을 높일 수 있음

빌더 패턴을 사용하면 매개변수가 많아져도 가독성을 높일 수 있다. 생성자로 객체를 생성하는 경우에는 매개변수가 많아질수록 코드 리딩이 급격하게 떨어진다. 예를 들어 다음과 같은 코드가 있다고 하자.

Employee employee = new Employee("E01", "박범성", 28, "01000010001");

 

 

위와 같은 코드를 보면 "E01"과 28 또는 "01000010001"이 무엇을 의미하는지 바로 파악이 힘들고, 클래스 변수가 많아질수록 더욱 코드를 읽기 힘들어진다. 하지만 다음과 같이 빌더 패턴을 적용하면 직관적으로 어떤 데이터에 어떤 값이 설정되는지 쉽게 파악하여 가독성을 높일 수 있다.

Employee employee = Employee.builder()
             .id("E01")
             .name("박범성")
             .age(28)
             .tel("01000010001").build();

 

 

 

(4)  변경 가능성을 최소화할 수 있음

많은 개발자들이 수정자 패턴(Setter)를 흔히 사용한다. 하지만 Setter를 구현한다는 것은 불필요하게 변경 가능성을 열어두는 것이다. 이는 유지보수 시에 값이 할당된 지점을 찾기 힘들게 만들며 불필요한 코드 리딩 등을 유발한다.

 만약 값을 할당하는 시점이 객체의 생성뿐이라면 객체에 잘못된 값이 들어왔을 때 그 지점을 찾기 쉬우므로 유지보수성이 훨씬 높아질 것이다. 그렇기 때문에 클래스 변수는 변경 가능성을 최소화하는 것이 좋다.

변경 가능성을 최소화하는 가장 좋은 방법은 변수를 final로 선언함으로써 불변성을 확보하는 것이다.

 

위의 Employee 클래스를 다음과 같이 수정할 수 있다.

@Builder
@RequiredArgsConstructor
public class Employee  {
    private final String id;
    private final String name;
    private final int age;
    private final String tel;
}

 

 

하지만 경우에 따라서 클래스 변수에 final을 붙일 수 없는 경우가 있을 수 있다. 이러한 경우라면 final이 없어도 Setter를 구현하지 않음으로써 동일한 효과를 얻을 수 있다. 중요한 것은 변경 가능성을 열어두지 않는 것인데, final로 강제할 수 있다면 가장 바람직하지만 final을 붙일 수 없는 경우라면 Setter를 넣어주지 않으면 된다.

@Builder
@AllArgsConstructor
public class Employee {
    private String id;
    private String name;
    private int age;
    private String tel;
}

 

 

 

3. 결론

 

객체를 생성하는 대부분의 경우에는 빌더 패턴을 적용하는 것이 좋다. 물론 예외적인 케이스가 있을 수 있는데,

대표적으로 크게 다음의 2가지 상황에서는 빌더를 구현할 필요가 없다.

• 객체의 생성을 라이브러리로 위임하는 경우
• 변수의 개수가 2개 이하이며, 변경 가능성이 없는 경우

 

예를 들어 엔티티(Entity) 객체나 도메인(Domain) 객체로부터 DTO를 생성하는 경우라면 직접 빌더를 만들고 하는 작업이 번거로우므로 MapStruct나 Model Mapper와 같은 라이브러리를 통해 생성을 위임할 수 있다.

 또한 변수가 늘어날 가능성이 거의 없으며, 변수의 개수가 2개 이하인 경우에는 정적 팩토리 메소드를 사용하는 것이 더 좋을 수도 있다. 빌더의 남용은 오히려 코드를 비대하게 만들 수 있으므로  변수의 개수와 변경 가능성 등을 중점적으로 보고 빌더 패턴을 적용할지 판단하면 된다.

 

 

다른 사람과 협업을 하거나 변경에 대한 요구 사항이 많은 경우라면 빌더 패턴을 사용해야 하는 이유를 더욱 극명하게 느낄 수 있다. 만약 아직 객체의 생성을 위해 생성자나 수정자 패턴 또는 정적 메소드 패턴을 사용하고 있다면 롬복을 사용해 빌더 패턴을 적용하도록 하자.

 

---

#References

https://readystory.tistory.com/121

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

https://mangkyu.tistory.com/163