한빛출판네트워크

작성: 한동훈(traxacun at unitel.co.kr)

작성일: 2003. 2. 7
수정일: 2003. 2. 24

Builder Pattern

Builder 패턴은 Abstract Factory 패턴과 가장 자주 비교가 된다. 이 둘은 상당히 비슷하지만 다음과 같은 차이점을 갖고 있다.

Abstract Factory 패턴은 한 번 호출될 때마다 하나의 제품(Product)을 생산하는데 필요한 관련된 모든 부품(Parts)들을 반환한다. 즉, 페라리를 만들기 위해 페라리에 관련된 모든 부품을 반환하지만 완전한 제품을 반환하지는 않는다. 반환된 일련의 부품을 이용한 조립 과정은 다른 클래스에 맡겨진다.(이전 글을 읽어본 독자라면 Environment 클래스를 생각해보기 바란다. Abstract Factory는 하나의 제품에 필요한 부품을 반환할뿐 어떠한 조립과정도 없으며 이 조립과정은 Environment 클래스에 있다.)

반면에 Builder 패턴은 객체의 내부 상태에 따라 단계별로 부품을 생성하여 완전한 하나의 제품을 반환하기 때문에 Builder 패턴은 조립자(Assembler)의 역할을 하는 것이 보통이다. 이 차이점을 염두에 두고 이전에 소개한 Abstract Factory 패턴과 여기서 소개할 Builder 패턴을 살펴보면 좋을 것이다.

그림1. Builder

여기서는 Collection을 사용하여 Product 클래스 하나를 사용하였으나 GoF의 다이어그램에는 Product 클래스가 ConcreteBuilder1.BuildPartA()에는 ProductA1, ConcreteBuilder2.BuildPartA()에는 ProductA2 클래스로 되어 있으며 마찬가지로 ConcreteBuilder.BuildPartB()에는 각각 ProductB1, ProductB2 클래스로 되어 있다. 마찬가지로 Product 클래스가 반드시 나뉘어져 있을 필요가 있는 것은 아니다.

Builder 패턴에 대한 예로 많이 인용되는 예로는 UIBuilder가 있다. 만약 사용자가 개발하는 시스템이 다양한 운영체제의 UI를 지원한다고 생각해보자. UIBuilder는 사용자의 시스템이 UNIX 환경이면 Motif 위젯을 사용할 것이고, Windows 환경이라면 Windows 위젯을 사용하며, Mac 환경이라면 Mac 환경의 UI를 사용할 것이다. 이 경우에 UI(Director)는 UIBuilder(Builder)에 의해 조립될 것이고, 각 UI에 따라 적절한 ConcreteBuilder가 선택될 것이다.

또 다른 예로는 상점이 있다. Shop(Director)은 다양한 탈것(Vehicle)들의 정보를 보여줄 수 있으며, 상점에는 다양한 종류의 탈것(Bicycle, Car, Scooter, Truck)들이 있을 것이다.

대부분의 DP 책들에 위 두 가지 예가 소개되어 있으므로 여기서 자세히 설명하지 않아도 자주 보게 될 것이다.

각 클래스의 소스 코드는 다음과 같다.

그림2. Director 클래스

그림3. Builder 클래스

그림4. ConcreteBuilder1 클래스

그림5. ConcreteBuilder2 클래스

그림6. Product 클래스

그림7. Tester 클래스

마치며

지금까지 몇가지 생성패턴을 살펴보았고 다음에는 Prototype 패턴에 대해서 살펴볼 것이다. GoF의 디자인 패턴 책에 소개된 생성 패턴외에 Utility 패턴과 Monostate 패턴에 대해서도 설명하였다. 마찬가지로 Prototype 패턴은 Examplar 패턴과 유사하며, Prototype 패턴을 적용하는 경우에 대하여 Object Type 패턴을 적용하는 것이 더 좋은 경우도 있다. 개인적으로는 많은 분들이 이야기하는 것처럼 철저한 분석과 설계를 통해서 DP를 적용해 나가야한다고 하지만 필자는 XP와 같은 주먹구구식(?) 방법과 개발 과정중에 필요에 따라 설계가 변하면서 자연스럽게 패턴이 적용되어야한다고 생각한다. 어차피 이 모든 것은 독자의 선택이겠지만 말이다.