의도
- 복잡한 객체를 생성하는 방법과 표현하는 방법을 정의하는 클래스를 별도로 분리하여, 서로 다른 표현이라도 이를 생성할 수 있는 동일한 절차를 제공할 수 있도록 함
동기
- RTF 문서 판독기의 예시를 들고 있다.
- RTF 문서 판독기는 RTF 포멧에서 다른 텍스트 포멧으로 바꿀 수 있어야한다.(ex. ASCII 문서 등등)
- RTF 문서 판독기는 RTF Reader와 Text Convertor로 나눌 수 있겠다.
- RTF Reader에서 RTF token을 판독할 때 마다, Text Converter에게 토큰을 변환하도록 보낼 수 있게 하면 될 것이다.
- TextConverter의 서브 클래스들은 서로 다른 포멧을 변환할 수 있도록 구체 클래스로 구성되어 있을 것이다.
- 그리고 각 서브 클래스들은 복잡한 최종 text(ex. ASCII text, TeXText, TexWidget) 을 생성하기 위해 조립하는 기능을 각 인터페이스의 각 연산에 구현한다.
- 빌더 패턴은 이럴때 사용 된다. 각 서브 클래들이 바로 빌더 패턴에서 쓰는 빌더이고, 판독기는 디렉터(Director)라고 칭한다.
- 이렇게 판독하는 기능과 Converting 하는 기능을 분리해내는 데 쓰일 수 있음.
활용성
- 복합 객체의 생성 알고리즘이 이를 합성하는 요소 객체들이 무엇인지 이들의 조립 방법에 독립적일 때
- 합성할 객체들의 표현이 서로 다르더라도 생성 절차에서 이를 지원해야할 때
구조

참여자
-
Builder(TextConverter)
- Product 객체의 일부 요소들을 생성하기 위한 추상 인터페이스 정의
-
ConcreteBuilder (ASCIIConverter,TeXconverter...)
- 구체적인 제품의 부품들을 모아 빌더를 복합한다. 또 Product를 검색하기 위한 getter제공
-
Director(RTF Reader)
- Builder 인터페이스를 사용하는 객체를 최종적으로 합성하는 역할
-
Product(ASCIIext...)
협력 방법
-
사용자는 Director 객체를 생성하고, 이렇게 생성한 객체를 자신이 원하는 Builder 객체로 합성해 나간다.
-
제품의 일부가 구축 될 때마다, director는 builder에 통보
-
builder는 director 요청을 처리하여, 제품에 부품을 추가
-
사용자는 builder에서 제품을 검색함
구현 방법
builder pattern 위키 링크
소감
- 구글링 해봐도 적합한 예제를 못찾겠다. 그나마 Wiki의 Pizza예제와 유사한 것 같지만 Abstract Factory Method와 거의 동일 한 방법 인 것 같다.
- 어쨋든 두개는 유사하다고 책에서도 나와 있고, 다만 차이점은, Builder 패턴은 최종 시점에 Director클래스가 Construct를 해야만 객체가 나타난다는 점이다.
- 책에서 나온, RTF 판독기가 그나마 이해하기 괜찮은 것 같은데, 사실 이 패턴은 손에 잘 안익어서 잘 못 쓸 것 같다.
- 자바 진영의 Builder 패턴과 GoF가 말하는 Builder 패턴은 완전 다른거다.
- 검색 상단에서 뜨는 블로그글들에서 틀린게 참 많은 것 같다.
참고 자료
https://hamait.tistory.com/847