DesignPatternSmalltalkCompanion:Builder - Revision history

Onionmixer: 따옴표 수정

2013-01-27T15:49:38Z

따옴표 수정

← Older revision		Revision as of 15:49, 27 January 2013
Line 46:		Line 46:
	====부품추가하기====		====부품추가하기====

	Builder는 내부 상태에 대한 몇 가지 양식을 가진다: 하위컴포넌트 명세를 수신하면 Builder는 캡슐화된 제품에 새 부품을 추가한다. 사실 Builder는 Director가 "어떠어떠한 부품을 추가하라" 라거나 "어떠어떠한"" 명세를 말할 때마다 하위컴포넌트를 인스턴스화하면서 결과 받기 메시지가 수신될 때 전체적 최종 제품을 구축할 수 있는 선택을 가진다. 그럼에도 불구하고 어떤 경우든 최종 제품이 클라이언트에 의해 검색될 때까지 일부 데이터는 Builder 내에서 캡슐화된다.		Builder는 내부 상태에 대한 몇 가지 양식을 가진다: 하위컴포넌트 명세를 수신하면 Builder는 캡슐화된 제품에 새 부품을 추가한다. 사실 Builder는 Director가 "어떠어떠한 부품을 추가하라" 라거나 "어떠어떠한" 명세를 말할 때마다 하위컴포넌트를 인스턴스화하면서 결과 받기 메시지가 수신될 때 전체적 최종 제품을 구축할 수 있는 선택을 가진다. 그럼에도 불구하고 어떤 경우든 최종 제품이 클라이언트에 의해 검색될 때까지 일부 데이터는 Builder 내에서 캡슐화된다.

	~~“부품 추가”~~ 주제에는 최소 3개의 변형이 있다.		"부품 추가" 주제에는 최소 3개의 변형이 있다.

	# 양방향 다이어그램은 Director가 Builder에게 제품에 특정 부품 유형을 추가하라고 말해주는데 그친다는 사실을 보여준다ㅡA형 컴포넌트를 추가하기, B형 부품을 추가하기, 4개의 실린더형 엔진을 추가하기, 2개문 쿠페 차체 추가하기를 예로 들 수 있다. Builder는 적절한 클래스를 인스턴스화하고 개발 중인 제품에 새 부품을 추가한다.		# 양방향 다이어그램은 Director가 Builder에게 제품에 특정 부품 유형을 추가하라고 말해주는데 그친다는 사실을 보여준다ㅡA형 컴포넌트를 추가하기, B형 부품을 추가하기, 4개의 실린더형 엔진을 추가하기, 2개문 쿠페 차체 추가하기를 예로 들 수 있다. Builder는 적절한 클래스를 인스턴스화하고 개발 중인 제품에 새 부품을 추가한다.
Line 127:		Line 127:
	[[image:dpsc_chapter03_builder_03.png]]		[[image:dpsc_chapter03_builder_03.png]]

	'''ToyotaEngine, PorscheEngine, FordBody, ToyotaBody, PorscheBody''' 아래에도 서로 비슷한 하위계층구조가 있을 것이고 기타 모든 컴포넌트에도 마찬가지다. 이 애플리케이션에서 Builder 부분과 관련해서는 CarBuilder 계층구조를 정의함으로써 시작한다"		'''ToyotaEngine, PorscheEngine, FordBody, ToyotaBody, PorscheBody''' 아래에도 서로 비슷한 하위계층구조가 있을 것이고 기타 모든 컴포넌트에도 마찬가지다. 이 애플리케이션에서 Builder 부분과 관련해서는 CarBuilder 계층구조를 정의함으로써 시작한다.

	[[image:dpsc_chapter03_builder_04.png]]		[[image:dpsc_chapter03_builder_04.png]]

Onionmixer: 메소드 > 메서드 수정

2013-01-08T10:27:07Z

메소드 > 메서드 수정

Show changes

Onionmixer at 05:09, 28 July 2012

2012-07-28T05:09:18Z

← Older revision		Revision as of 05:09, 28 July 2012
Line 49:		Line 49:
	“부품 추가” 주제에는 최소 3개의 변형이 있다.		“부품 추가” 주제에는 최소 3개의 변형이 있다.

	1. 양방향 다이어그램은 Director가 Builder에게 제품에 특정 부품 유형을 추가하라고 말해주는데 그친다는 사실을 보여준다ㅡA형 컴포넌트를 추가하기, B형 부품을 추가하기, 4개의 실린더형 엔진을 추가하기, 2개문 쿠페 차체 추가하기를 예로 들 수 있다. Builder는 적절한 클래스를 인스턴스화하고 개발 중인 제품에 새 부품을 추가한다.		# 양방향 다이어그램은 Director가 Builder에게 제품에 특정 부품 유형을 추가하라고 말해주는데 그친다는 사실을 보여준다ㅡA형 컴포넌트를 추가하기, B형 부품을 추가하기, 4개의 실린더형 엔진을 추가하기, 2개문 쿠페 차체 추가하기를 예로 들 수 있다. Builder는 적절한 클래스를 인스턴스화하고 개발 중인 제품에 새 부품을 추가한다.
	1. Director는 Builder에게 “원재료”를 건네주면서 Builder에게 어떤 원재료 부품을 변형시켜 그 결과를 제품에 추가하라고 말하기도 한다. [디자인 패턴]에서는 하나의 양식으로 (예: Rich Text 양식) 된 파일 내 정보를 다른 양식으로 (예: TeX) 변환시키는 예제를 보여준다. 그러므로 “부품을 추가하라”는 요청은 “여기 RTF 폰트변경 토큰이 있다; 이것을 텍스트 폰트변경 명세로 변환한 후 너의 제품에 추가한다’”는 뜻을 암시하는지도 모른다. 따라서 Builder는 적절한 클래스를 단순히 인스턴스화시키기보다는 특별한 지식과 경험으로 구현되어야 한다.		# Director는 Builder에게 “원재료”를 건네주면서 Builder에게 어떤 원재료 부품을 변형시켜 그 결과를 제품에 추가하라고 말하기도 한다. [디자인 패턴]에서는 하나의 양식으로 (예: Rich Text 양식) 된 파일 내 정보를 다른 양식으로 (예: TeX) 변환시키는 예제를 보여준다. 그러므로 “부품을 추가하라”는 요청은 “여기 RTF 폰트변경 토큰이 있다; 이것을 텍스트 폰트변경 명세로 변환한 후 너의 제품에 추가한다’”는 뜻을 암시하는지도 모른다. 따라서 Builder는 적절한 클래스를 단순히 인스턴스화시키기보다는 특별한 지식과 경험으로 구현되어야 한다.
	1. Director는 Builder에게 컴포넌트에 대한 추상 사양을 제공하며, 이 사양을 해석하고 이를 바탕으로 객체를 생성한 후 이렇게 만들어진 객체를 제품으로 추가하는 일은 Builder에게 맡긴다. 이는 꼭 비주얼웍스의 UIBuilder에서 이루어져야 한다: 비주얼웍스 UIPainter는 사용자가 사용자 인터페이스(UI) 윈도우의 위젯을 배열하도록 하고 이 레이아웃을 바탕으로 추상 사양을 생성한다. 여기에는 모든 윈도우 위젯에 대한 명세를 포함한다: 유형, 위치, 크기, 내용 (예: 라벨에 텍스트 표시) 등이 포함된다. 이러한 명세는 UI 윈도우와 관련된 애플리케이션 클래스의 메소드에 저장된다. 애플리케이션이 시작할 때 이에 해당하는 “윈도우 사양”은 각 위젯을 생성하고 전체 윈도우로 추가시키는 UIBuilder로 전달된다.		# Director는 Builder에게 컴포넌트에 대한 추상 사양을 제공하며, 이 사양을 해석하고 이를 바탕으로 객체를 생성한 후 이렇게 만들어진 객체를 제품으로 추가하는 일은 Builder에게 맡긴다. 이는 꼭 비주얼웍스의 UIBuilder에서 이루어져야 한다: 비주얼웍스 UIPainter는 사용자가 사용자 인터페이스(UI) 윈도우의 위젯을 배열하도록 하고 이 레이아웃을 바탕으로 추상 사양을 생성한다. 여기에는 모든 윈도우 위젯에 대한 명세를 포함한다: 유형, 위치, 크기, 내용 (예: 라벨에 텍스트 표시) 등이 포함된다. 이러한 명세는 UI 윈도우와 관련된 애플리케이션 클래스의 메소드에 저장된다. 애플리케이션이 시작할 때 이에 해당하는 “윈도우 사양”은 각 위젯을 생성하고 전체 윈도우로 추가시키는 UIBuilder로 전달된다.

	====다수의 제품군====		====다수의 제품군====

Onionmixer at 05:06, 28 July 2012

2012-07-28T05:06:24Z

← Older revision		Revision as of 05:06, 28 July 2012
Line 6:		Line 6:
	===구조===		===구조===

	~~{{{~~[그림]~~}}}~~		[[image:dpsc_chapter03_builder_01.png]]

	===논의===		===논의===
Line 37:		Line 37:
	다음 상호작용 다이어그램은 Builder 패턴의 협력을 설명한다. 이는 [디자인 패턴]편 DP 99 페이지에 실린 협력 다이어그램과 다른데, 그곳에 실린 다이어그램에는 Director 객체와 그 Director에 대한 클라이언트가 모두 포함되어 있으며, Director에 대한 클라이언트는 애플리케이션에 중요한 객체로 추정된다. 우리는 굳이 둘 다 필요하지 않은 것으로 생각된다; Director가 애플리케이션과 Builder 사이를 방해할 이유가 없다. 다시 말하지만 패턴을 그런 식으로 구현하도록 선택할 수는 있지만 개인의 미학에 관한 문제이다. 애플리케이션 자체가 빌딩 과정을 책임져야 하는가, 아니면 별도의 Director에 태스크를 위임해야 하는가? 본 패턴 예제에서는 애플리케이션이 Director의 역할을 맡도록 한다.		다음 상호작용 다이어그램은 Builder 패턴의 협력을 설명한다. 이는 [디자인 패턴]편 DP 99 페이지에 실린 협력 다이어그램과 다른데, 그곳에 실린 다이어그램에는 Director 객체와 그 Director에 대한 클라이언트가 모두 포함되어 있으며, Director에 대한 클라이언트는 애플리케이션에 중요한 객체로 추정된다. 우리는 굳이 둘 다 필요하지 않은 것으로 생각된다; Director가 애플리케이션과 Builder 사이를 방해할 이유가 없다. 다시 말하지만 패턴을 그런 식으로 구현하도록 선택할 수는 있지만 개인의 미학에 관한 문제이다. 애플리케이션 자체가 빌딩 과정을 책임져야 하는가, 아니면 별도의 Director에 태스크를 위임해야 하는가? 본 패턴 예제에서는 애플리케이션이 Director의 역할을 맡도록 한다.

	~~{{{~~[~~그림}}}~~		[[image:dpsc_chapter03_builder_02.png]]

	본 예제의 다이어그램이 다른 이유는 스몰토크에서는 인스턴스 생성을 위해 클래스 객체로 전송되는 런타임 메시지를 설명할 필요가 있기 때문이다. Builder 클래스가 선택되어 인스턴스화되고 나면 Director는 Builder 객체에게 새 부품을 구축할 것을 반복 요청한다 (addPartA, addPartB, addPartC 메시지). 이에 응해 Builder는 개발 중인 제품에 부품을 추가한다. 하위컴포넌트 부품이 추가되면 Builder는 어떤 이해관계든 응답하지 (반환하지) 않는다 (모든 메소드는 무언가를 반환하기 때문에 수신자(receiver) 객체인 Builder는 자동적으로 반환된다). 빌딩 과정이 완료되면 Director는 Builder에게 getResult를 전송함으로써 최종 제품을 요청한다.		본 예제의 다이어그램이 다른 이유는 스몰토크에서는 인스턴스 생성을 위해 클래스 객체로 전송되는 런타임 메시지를 설명할 필요가 있기 때문이다. Builder 클래스가 선택되어 인스턴스화되고 나면 Director는 Builder 객체에게 새 부품을 구축할 것을 반복 요청한다 (addPartA, addPartB, addPartC 메시지). 이에 응해 Builder는 개발 중인 제품에 부품을 추가한다. 하위컴포넌트 부품이 추가되면 Builder는 어떤 이해관계든 응답하지 (반환하지) 않는다 (모든 메소드는 무언가를 반환하기 때문에 수신자(receiver) 객체인 Builder는 자동적으로 반환된다). 빌딩 과정이 완료되면 Director는 Builder에게 getResult를 전송함으로써 최종 제품을 요청한다.
Line 124:		Line 124:
	추상 팩토리에 사용된 제품 클래스가 비슷하다고 가정하되, 클래스 수는 이 경우가 더 많을 것이다. 옵션의 선택을 허용하기 때문에 FordEngine 클래스 뿐만 아니라 다음과 같이 더 많은 클래스가 있을 것이다.		추상 팩토리에 사용된 제품 클래스가 비슷하다고 가정하되, 클래스 수는 이 경우가 더 많을 것이다. 옵션의 선택을 허용하기 때문에 FordEngine 클래스 뿐만 아니라 다음과 같이 더 많은 클래스가 있을 것이다.

	~~{{{~~[그림]~~}}}~~		[[image:dpsc_chapter03_builder_03.png]]

	'''ToyotaEngine, PorscheEngine, FordBody, ToyotaBody, PorscheBody''' 아래에도 서로 비슷한 하위계층구조가 있을 것이고 기타 모든 컴포넌트에도 마찬가지다. 이 애플리케이션에서 Builder 부분과 관련해서는 CarBuilder 계층구조를 정의함으로써 시작한다"		'''ToyotaEngine, PorscheEngine, FordBody, ToyotaBody, PorscheBody''' 아래에도 서로 비슷한 하위계층구조가 있을 것이고 기타 모든 컴포넌트에도 마찬가지다. 이 애플리케이션에서 Builder 부분과 관련해서는 CarBuilder 계층구조를 정의함으로써 시작한다"

	~~{{{~~[그림]~~}}}~~		[[image:dpsc_chapter03_builder_04.png]]

	<syntaxhighlight lang="smalltalk">		<syntaxhighlight lang="smalltalk">
Line 206:		Line 206:
	이제 예제 애플리케이션의 사용자 인터페이스에 대해 이야기해보자. 사용자는 메뉴로부터 자동차 제조업체를 선택한 후 해당 메뉴로부터 엔진 유형, 차체 유형, 기타 특성을 선택할 수 있을 것이다. 사용자가 여태까지 구축한 것을 보고 싶다면 Action 메뉴에서 Draw를 선택한다. 이에 대한 응답으로 애플리케이션은 그래픽 창에서 자동차를 표시한다 (메뉴 바 아래). 사용자가 자동차를 주문하고 싶어한다면 동일한 메뉴에서 Order를 선택한다. 사용자 인터페이스는 다음과 같은 모습일 것이다 (Audio System, Trim, 기타 하위컴포넌트에 풀다운 메뉴가 추가될 것이다).		이제 예제 애플리케이션의 사용자 인터페이스에 대해 이야기해보자. 사용자는 메뉴로부터 자동차 제조업체를 선택한 후 해당 메뉴로부터 엔진 유형, 차체 유형, 기타 특성을 선택할 수 있을 것이다. 사용자가 여태까지 구축한 것을 보고 싶다면 Action 메뉴에서 Draw를 선택한다. 이에 대한 응답으로 애플리케이션은 그래픽 창에서 자동차를 표시한다 (메뉴 바 아래). 사용자가 자동차를 주문하고 싶어한다면 동일한 메뉴에서 Order를 선택한다. 사용자 인터페이스는 다음과 같은 모습일 것이다 (Audio System, Trim, 기타 하위컴포넌트에 풀다운 메뉴가 추가될 것이다).

	~~{{{~~[그림]~~}}}~~		[[image:dpsc_chapter03_builder_05.png]]

	사용자 인터페이스가 CarAssemblerUI 객체에 의해 구현된다고 하자. CarAssemblerUI는 CarBuilder 인스턴스로 구성되고, CarAssemblerUI는 Builder에게 사용자 선택을 바탕으로 자동차 컴포넌트를 생성시켜 추가하라고 전한다. 비주얼 스몰토크(Visual Smalltalk)에서 이 애플리케이션을 구현하는 코드를 소개하겠다. 첫째, 우리는 사용자 인터페이스 애플리케이션을 ViewManager의 서브클래스로서 정의한다:		사용자 인터페이스가 CarAssemblerUI 객체에 의해 구현된다고 하자. CarAssemblerUI는 CarBuilder 인스턴스로 구성되고, CarAssemblerUI는 Builder에게 사용자 선택을 바탕으로 자동차 컴포넌트를 생성시켜 추가하라고 전한다. 비주얼 스몰토크(Visual Smalltalk)에서 이 애플리케이션을 구현하는 코드를 소개하겠다. 첫째, 우리는 사용자 인터페이스 애플리케이션을 ViewManager의 서브클래스로서 정의한다:
Line 333:		Line 333:
	구조적으로 우리 애플리케이션은 다음 다이어그램과 같은 모양이다:		구조적으로 우리 애플리케이션은 다음 다이어그램과 같은 모양이다:

	~~{{{~~[그림]~~}}}~~		[[image:dpsc_chapter03_builder_06.png]]

	이와 유사한 추상 팩토리 다이어그램과 이 그림 간 차이를 찾아보자. 추상 팩토리에서 팩토리는 개별적 컴포넌트를 생성하도록 요청받을 수 있고, 적절한 객체를 반환시키기도 한다. 팩토리 클라이언트가 원한다면 이 부품들 각각을 더 큰 제품으로 추가할 수도 있지만 팩토리 자체는 이를 알지 못한다.		이와 유사한 추상 팩토리 다이어그램과 이 그림 간 차이를 찾아보자. 추상 팩토리에서 팩토리는 개별적 컴포넌트를 생성하도록 요청받을 수 있고, 적절한 객체를 반환시키기도 한다. 팩토리 클라이언트가 원한다면 이 부품들 각각을 더 큰 제품으로 추가할 수도 있지만 팩토리 자체는 이를 알지 못한다.

Onionmixer: DPSC BUILDER 페이지 추가

2012-07-27T09:28:46Z

DPSC BUILDER 페이지 추가

Show changes