The Builder Pattern

    우리는 이미 생성 메소드의 인자로 넘겨지는 데이터에 의존하는 여러개의 서로 다른 하위 클래스 중의 하나를 반환하는 Factory 패턴을 보았었다. 그러나 단지 계산 알고리즘 뿐만 아니라 나타낼 필요가 있는 데이터에 의존하는 서로 다른 사용자 인터페이스를 가정해 보자. 전형적인 예는 이메일 주소록이 될 것이다. 아마 주소록에는 사람들과 사람들의 그룹 둘 다 가지고 있을 것이고, 사람이름, 회사, 이메일 주소, 전화번호를 가지고 있는 사람창을 변경시키기 위해 주소록을 디스플래이하기를 기대하게 될 것이다.

    반면에 주소 페이지에서 그룹을 표시하고자 한다면, 그룹의 이름을 보고자 할 것이다. 한 사람을 클릭하면 그룹과 다른 것들을 얻을 수 있다. 모든 이메일 주소는 아래 그림처럼 사람과 그룹을 파생시키는 상위 클래스 주소를 갖는 다고 가정하자:

            ##########0*

    우리가 누르는 주소 객체의 타입에 따라, 객체들의 다른 속성을 나타내기를 원할 것이다. 이것은 팩토리 패턴보다는 약간 더 증가한 것인데, 왜냐하면 보여줄 객체에 의존하는 객체들을 반환하는 것이 아니라 전체적으로 다른 사용자 인터페이스가 보여줄 객체들의 서로 다른 조합을 만드는 것이기 때문이다. 빌더 패턴은 객체들을 조합하는 것이다. 

An Investment Tracker

    사용자 인터페이스를 세울 클래스를 어디에서 유용하게 사용될 수 있는지를 고려해 보자. 투자의 수행을 추적하는 프로그램을 작성하고자 한다고 하자. 우리는 주식, 채권, 상호 기금 등을 가질 수 있고, 각 범주의 보유 목록을 나타내고자 하고 그래서 하나 또는 이상의 투자를 선택하고 그것들의 상대적인 성취도를 표시하고자 한다. 우리가 어떤 주어진 시간에 얼마나 많은 투자의 종류가 있는지 미리 예측할 수는 없다 하더라도 쉽게 대규모의 기금이나 소규모의 기금이 사용되는지를 나타내고자 한다. 각각의 경우에, 우리는 하나 또는 그 이상의 기름을 선택할 수 있는 다중 선택 디스플레이를 정렬하고자 한다. 만약 대규모의 기금이 있다면, 우리는 다중 선택이 가능한 리스트 박스를 사용할 것이고, 3개 또는 몇 안되는 기금이 있으면 체크박스를 사용할 것이다. 우리는 표시 될 항목의 수에 따라 인터페이스를 생성하는 빌더 클래스를 원하고, 아직까지 결과를 반환하기 위한 같은 메소드들을 가지고 있다. 

    우리의 디스플레이들은 아래에서 보여진다. 첫번째 디스플레이는 대규모의 주식을 포함하고 두번째는 소규모의 채권을 포함하고 있다. 

            ##########1* 

            ##########2*

    이제, 변수들을 나타낼 인터페이스를 어떻게 생성할 수 있는지 고려해 보자. 우리는 구현 할 필요가 있는 메소드를 정의한 multiChoice라는 추상 클래스로부터 시작해 보자.

abstract class multiChoice {

	//This is the abstract base class
	//that the listbox and checkbox choice panels
	//are defived from
	Vector choices;	//array of labels
	
	//---------------------------------------
	
	public multiChoice(Vector choiceList) {
		choices = choiceList;	//save the list
	}
	
	//to be implemented in derived classes
	abstract public JPanel getUI();	//return a Panel of components
	abstract public String[] getSelected();	//get list of items
	abstract public void clearAll();	//clear selections
}

getUI 메소드는 다중 선택을 나타내는 패널을 반환한다. 여기서 우리가 사용하는 두 개의 디스플레이는 체크박스 패널 또는 리스트박스 패널이다. -- 이 추상 클래스로부터 상속 받은 

class listboxChoice extends multiChoice 
            또는
class checkBoxChoice extends multiChoice

그리고 나서, 이 두개의 상속 받은 클래스를 반환할 팩토리 클래스를 만든다:

class choiceFactory {

	MultiChoice ui;
	//This class returns a Panel containing
	//a set of choices displayed by one of 
	//several UI methods
	public MultiChoice getChoiceUI(Vector choices) {
		if(choices.size()<=3)
			//return a panel of checkboxes
			ui = new checkBoxChoice(choices);
		else
			//return a multi-select list box panel
			ui = new listBoxChoice(choices);
		
		return ui;
	}
}

Consequences of the Builder Pattern

  1. 빌더는 세워지는 것의 내부적인 표현을 변경할 수 있게 한다. 또, 어떻게 생성된 것이 조립되었는지를 감추어 준다.
  2. 각각의 특수한 빌더는 프로그램의 나머지 부분과는 독립적이다. 이것이 모듈화를 향상시키고 상대적으로 간단하게 다른 빌더들을 추가적으로 만들어 준다 
        빌더 패턴은 일련의 메소드와 객체들로 이루어진 클래스를 반환한다는 점에서는 추상화 패턴과 유사하다. 두 패턴 사이의 중요한 차이는 추상화 팩토리 패턴이 관련된 클래스의 하나의 족을 반환하는데 반해 빌더는 표현해야 하는 데이터에 의존하는 복잡한 객체를 단계적으로 생성한다는데 있다. 

'Development > 패턴자료' 카테고리의 다른 글

[펌] The Command Pattern  (0) 2011.08.13
[펌] The Chain of Responsibility Pattern  (0) 2011.08.13
[펌] The Bridge Pattern  (0) 2011.08.13
[펌] The Adapter Pattern  (0) 2011.08.13
[펌] The Abstract Factory Pattern  (0) 2011.08.13
안정적인 DNS서비스 DNSEver DNS server, DNS service
Posted by 키르히아이스
,