[Design Patterns] Builder

목차

 

개요

이번 글에선 Object Creational Pattern인 빌더 패턴을 알아보겠습니다.

내용

요약

복잡한 객체의 생성을 별도의 클래스로 따로 분리하자.

 

예시

건축자가 집을 짓는다고 생각해봅시다. 집을 지을 때 건축자만 있으면 집을 지을 수 있을까요? 대게는 그렇지 않습니다. 건설같이 복잡한 작업을 할 땐 설계자가 도면을 그리고 건축자를 지휘해야 집을 지을 수 있습니다. 또한 지어야 하는 집의 양식에 따라 특화된 건축자 집단이 있을 수 있습니다. 나무 집에 특화된 건축자, 돌 집에 특화된 건축자 등등.. 

 

구조

빌더 패턴은 Director, Builder, Builder 구현체로 이뤄져 있습니다.

하지만 요즘에는 java StringBuilder처럼 Builder 구현체만 있어도 빌더 패턴으로 간주하기도 합니다. 이럴 땐 사용자가 director 역할을 수행해줘야 합니다. 이런 패턴은 <<Effective Java>>의 Item 2. Consider a builder when faced with many constructor parameters에 영향을 받은 것으로 추정됩니다.

 

이야깃거리

언제 써야 할까?

• 복잡한 객체를 만드는 과정(director)이 객체를 꾸미고 조립하는 부분(builder)과 나뉘어져야 할 때
• 객체 생성 과정이 반드시 만들어지는 객체의 다양한 표현을 허용해야 할 때. 즉, 위의 예시의 경우에서 집을 만들 때 나무 집, 돌 집 등등에 특화된 건축자 집단을 고용할 수 있어야 한다는 뜻.

장단점

• (Pros) 복잡한 객체를 만드는 과정을 추상화함으로써 사용자가 간단하게 객체를 생성할 수 있게 해줍니다.
• (Cons) 대부분의 디자인 패턴이 그렇듯, 코드의 복잡성을 증가시킵니다.

그 외

• 빌더 패턴에서는 builder 인터페이스에서 getXXX()와 같은 제품에 대한 인터페이스는 없습니다. 위 예에서도 창문, 벽 등등에 대한 일반화된 인터페이스를 정의하지 않았죠. 그 이유는 일반적으로 빌더 패턴의 결과로 만들어지는 제품들은 모두 매우 다르기 때문에 일관적인 인터페이스를 정의함으로써 얻는 이득이 거의 없기 때문입니다.
• 빌더 패턴에서는 builder 인터페이스의 메소드는 아무 작업도 하지않는 empty method를 기본 구현으로 제공해주면 좋습니다. Concrete builder 클래스가 필요한 메소드만 구현할 수 있게 말이죠

Case Study

1. BeanRegistrationCode

자바의 스프링 프레임워크에는 BeanRegistraitonCode라는 인터페이스가 있습니다. 이 인터페이스는 빈을 등록하기 위해 만들어지는 코드를 설정하기 위한 용도인데요. 실제로 이 인터페이스의 구현체인 BeanRegistrationCodeGenerator라는 클래스는 코드 블럭을 생성하는 generateCode라는 메소드를 가지고 있습니다. 그리고 이 generateCode가 빌더 패턴의 director처럼 동작합니다.

사실 Builder 클래스가 하나 뿐이란 점으로 인해 완전한 빌더 패턴으로 볼 순 없습니다만 변형된 빌더 패턴의 한 예로는 볼 수 있을 것 같습니다.

2. Joshua Bloch's Builder Patterns

<<Effective Java>> 에서 제안하는 빌더 패턴은 GoF의 빌더 패턴를 단순화시킨 버전으로 볼 수 있으며 다양한 곳에서 볼 수 있습니다. StringBuilder, Calendar.Builder, RestClient.builder 등등 자바에서 빌더 패턴을 말한다면 보통은 Joshua Bloch의 빌더 패턴을 의미하는 경우가 많습니다. 아마도 director 역할을 클라이언트에게 맡김으로써 더 높은 자율성을 보장해주기 때문인 것 같습니다.

 

출처

GoF's Design Patterns