[Java] Builder pattern

점층적 생성자 패턴

:  매개변수가 많아질 경우 가독성 유지보수가 어려움

 

자바 빈 패턴

: 일관성 문제 (객체를 생성하는 시점과 값을 설정하는 시점이 다를 경우 발생)

: 불변성 문제(객체를 생성한 후에도 setter 메서드를 통해 객체를 조작할 수 있음)

 

** 하단에 기재한, 참고 블로그에 설명이 자세히 잘 되어있으니 참고하기! 😎✨

---

빌더 패턴

위 두 패턴의 문제들을 해결하기 위해, 별도의 Builder 클래스를 만들어 메소드를 통해 단계적으로 값을 입력받은 후에 최종적으로 build() 메소드로 하나의 인스턴스를 생성하여 리턴하는 패턴

public static void main(String[] args) {

    // 생성자 방식
    Hamburger hamburger = new Hamburger(2, 3, 0, 3, 0, 0);

    // 빌더 방식
    Hamburger hamburger = new Hamburger.Builder(10)
        .bun(2)
        .patty(3)
        .lettuce(3)
        .build();
}
출처: https://inpa.tistory.com/entry/GOF-💠-빌더Builder-패턴-끝판왕-정리 [Inpa Dev 👨‍💻:티스토리]

빌더 패턴 네이밍 형식

① 멤버이름()  : .bun()   → 추천✨

② set멤버이름() : .setBun()

③ with멤버이름() : .withBun() 

---

빌더 패턴 장점

1. 객체 생성 과정을 일관된 프로세스로 표현

: 매개변수가 많아도, 직관적으로 파악 가능 & 설정 오류와 같은 실수 방지 가능

다만, 요즘에는 인텔리제이나 이클립스같은 IDE에서 생성자  매개변수에 대한 `미리보기 힌트 기능`을 제공해주기 때문에 요즘 트렌드에는 맞지 않을 수 있음

 

2. 디폴트 매개변수 생략을 간접적으로 지원

: 파이썬이나 자바스크립트와 달리 자바 언어에선 기본적으로 메서드에 대한 디폴트 매개변수를 지원하지 않는다.

따라서, 디폴트 매개변수를 구현하기 위해서는 클래스 필드 변수에 초기값을 미리 세팅하고 세팅된 필드 인자를 제외시킨 생성자를 따로 구현하는 방법으로 설계해야 하는데 결국 생성자 오버로딩 열거를 통한 본래의 문제점이 발생..

 

3. 필수 멤버와 선택적 멤버를 분리 가능

: 초기화가 필수인 멤버는 빌더의 생성자로 받게하여 필수 멤버를 설정해주어야 빌더 객체가 생성되도록 유도하고,

선택적인 멤버는 빌더의 메서드로 받도록 구분할 수 있음.

 

4. 객체 생성 단계를 지연할 수 있음

: 객체 생성을 단계별로 구성하거나 구성 단계를 지연하거나 재귀적으로 생성을 처리할 수 있다. 

: 빌더 클래스 전용 리스트를 생성하고, 여기에 초기값만 세팅한 빌더들을 추가한 후에 for문을 사용하여 리스트를 순회하며 최종 객체 생성 유도

 

5. 초기화 검증을 멤버별로 분리

: 생성자로부터 멤버값을 받는 형태인 경우, 각 생성자 매개변수에 대한 검증 로직을 생성자 메소드마다 복잡하게 구현해야 한다. 하지만, 빌더를 사용하면 생성될 객체의 멤버 변수의 초기화와 검증을 각각 멤버별로 분리해서 작성할 수 있어, 유지보수에 용이하다. 

 

6. 멤버에 대한 변경 가능성 최소화를 추구 

 

** 하단에 기재한, 참고 블로그에 설명이 자세히 잘 되어있으니 참고하기! 😎✨

 

빌더 패턴 단점

1. 코드 복잡성 증가

: N개의 클래스에 대해 N개의 새로운 빌더 클래스를 만들어야 해서, 클래스 수가 기하급수적으로 늘어나 관리해야 할 클래스가 많아지고 구조가 복잡해질 수 있다. 또한, 선택적 매개변수를 많이 받는 객체를 생성하기 위해서는 먼저 빌더 클래스부터 정의해야 한다.

 

2. 생성자 보다는 성능은 떨어진다

: 매번 메소드를 호출하여 빌더를 거쳐 인스턴스화 하기 때문에, 생성 비용 자체가 크지는 않지만 어플리케이션의 성능을 매우 중요시하는 상황이라면 문제가 될 수 있다.

 

3. 지나친 빌더 남용은 금지

: 클래스 필드의 개수가 4개 보다 적고, 필드 변경 가능성이 없는 경우라면 차라리 생성자나 정적 팩토리 메소드를 이용하는 것이 더 좋을 수 있다. 빌더 패턴의 코드가 다소 장황하기 때문이다. 클래스 필드의 갯수와 필드 변경 가능성을 중점으로 보고 패턴 적용 유무를 가려야 한다.

 

---

참고 및 출처 :

https://inpa.tistory.com/entry/GOF-%F0%9F%92%A0-%EB%B9%8C%EB%8D%94Builder-%ED%8C%A8%ED%84%B4-%EB%81%9D%ED%8C%90%EC%99%95-%EC%A0%95%EB%A6%AC

💠 빌더(Builder) 패턴 - 완벽 마스터하기