DesignPatternSmalltalkCompanion:1.4 - Revision history

Onionmixer: 단어수정

2018-07-24T08:26:27Z

단어수정

← Older revision		Revision as of 08:26, 24 July 2018
Line 11:		Line 11:
	* '''의도<sup>intent</sup>''' 단락에서는 가끔씩 다른 말로 변경한 부분이 있지만, [디자인 패턴] 본문을 그대로 발췌하였다.		* '''의도<sup>intent</sup>''' 단락에서는 가끔씩 다른 말로 변경한 부분이 있지만, [디자인 패턴] 본문을 그대로 발췌하였다.
	* 패턴의 '''구조<sup>Structure</sup>''' 다이어그램. 대부분 '''디자인 패턴''' 다이어그램과는 다르다. 더 명확한 설명을 위해 많은 구조 다이어그램을 수정했으며, Class 객체 등 Smalltalk 에 요구되는 객체를 포함하거나, C++ 의 구현과 패턴에 대한 Smalltalk 버전을 반영하고자 하였다. 구조적으로는 동일할지 몰라도 C++ 가 아닌 Smalltalk 구문과 의미론을 반영한다.		* 패턴의 '''구조<sup>Structure</sup>''' 다이어그램. 대부분 '''디자인 패턴''' 다이어그램과는 다르다. 더 명확한 설명을 위해 많은 구조 다이어그램을 수정했으며, Class 객체 등 Smalltalk 에 요구되는 객체를 포함하거나, C++ 의 구현과 패턴에 대한 Smalltalk 버전을 반영하고자 하였다. 구조적으로는 동일할지 몰라도 C++ 가 아닌 Smalltalk 구문과 의미론을 반영한다.
	* '''논의<sup>Discussion</sup>''' 부분에서는 패턴의 동기, Smalltalk 버전과 C++ ~~렌더링의~~ 차이, 패턴의 장단점, 패턴을 적용하려 할때 고민해야할 일반적인 사항들과 같은 주제들을 다룬다. 이 부분은 크리스토퍼 알렉산더의 패턴처럼 일반적인 설명으로 구성된다 (Alexander et al., 1977).		* '''논의<sup>Discussion</sup>''' 부분에서는 패턴의 동기, Smalltalk 버전과 C++ 해석의 차이, 패턴의 장단점, 패턴을 적용하려 할때 고민해야할 일반적인 사항들과 같은 주제들을 다룬다. 이 부분은 크리스토퍼 알렉산더의 패턴처럼 일반적인 설명으로 구성된다 (Alexander et al., 1977).
	* '''협력<sup>Collaborations</sup>''' 및 '''활용성<sup>Applicability</sup>''' 단락은 선택적이며, 때로는 논의 부분에서 다뤄지기도 한다.		* '''협력<sup>Collaborations</sup>''' 및 '''활용성<sup>Applicability</sup>''' 단락은 선택적이며, 때로는 논의 부분에서 다뤄지기도 한다.
	* '''구현<sup>Implementation</sup>''', Smalltalk 또는 일반적으로 패턴을 구현할때에 대한 관련 주제들을 다룬다.		* '''구현<sup>Implementation</sup>''', Smalltalk 또는 일반적으로 패턴을 구현할때에 대한 관련 주제들을 다룬다.

Onionmixer: 검수 20180724

2018-07-24T08:24:02Z

검수 20180724

← Older revision		Revision as of 08:24, 24 July 2018
Line 1:		Line 1:
	===1.4 ~~우리의 패턴~~ 논의===		===1.4 패턴에 대한 논의===

	~~GoF와 우리가 논하는~~ 패턴들은 특정 ~~추상 수준을 possess한다~~. 일반적으로 패턴은 ~~객체지향 애플리케이션에서 서로 다른 입자도(granularity)와~~ 추상화 수준에서 ~~발생하며, 그 범위는 마이크로부터 매크로까지이다~~. 메서드의 ~~변수를 어떻게 명칭을 할 것인지~~, 지연 초기화를 어떻게 구현할 것인지, 코드를 어떻게 ~~포맷할 것인지와~~ 저수준 문제들에 대한 ~~규약은~~ 마이크로패턴으로 간주한다 (Kent Beck의 ''Smalltalk Best Practice Pattern [1997b]''에 나오는 패턴의 다수는 이 범주에 속한다). 그 반대로 ~~VisualWorks의~~ 대화형 애플리케이션에 매우 중요한 아키텍처인 Model-View-Controller 프레임워크는 매크로패턴에 속한다. Buschmann et al.(1996)은 전체적으로 ~~패턴을~~ ''용어''부터 ''디자인 패턴''까지, 그리고 ''아키텍처 패턴''~~까지의 범위를 가진다고~~ 주장한다. 우리 디자인 패턴들은 핵심 분야에 중점을 둔다. 이 패턴들은 잘 ~~고안되고~~ 프로그램화된 ~~애플리케이션들의 일부에~~ 유용한 ~~마이크로아키텍처의~~ 구조와 구현을 설명한다.		GoF 와 여기서 논의하는 패턴들은 특정 수준의 추상화를 가지고 있다. 일반적으로 패턴은 마이크로에서 매크로에 이르는 넓은 범위의 객체 지향 응용 프로그램에서 다양한 수준의 세분성 및 추상화 수준에서 발생할 수 있다. 메서드의 변수에 어떤 이름을 붙일것 인지, 지연 초기화를 어떻게 구현할 것인지, 코드를 어떻게 형식화 시킬것인지와 저수준 문제들에 대한 규약등은 마이크로패턴으로 간주한다(Kent Beck의 ''Smalltalk Best Practice Pattern [1997b]''<ref name="역자주1">http://trans.onionmixer.net/mediawiki/index.php?title=SmalltalkBestPracticePatterns</ref>에 나오는 패턴의 다수는 이 범주에 속한다). 그 반대로 VisualWorks 의 대화형 애플리케이션에 매우 중요한 아키텍처인 Model-View-Controller 프레임워크는 매크로패턴에 속한다. Buschmann et al.(1996)은 전체적으로 패턴은 ''용어'' 부터 ''디자인 패턴''까지, 그리고 ''아키텍처 패턴'' 까지 다양하다고 주장한다. 여기서의 디자인 패턴들은 핵심 분야에 중점을 둔다. 이 패턴들은 잘 설계되고 프로그램화된 애플리케이션들에게 유용한 마이크로 아키텍처의 구조와 구현을 설명한다.

	'''디자인 패턴'''에서와 마찬가지로 이 책은 생성 패턴, 구조 패턴, 행위 패턴의 세 장으로 구성된다. 생성 ~~패턴에는~~ 객체의 생성 과정을 다룬다. 구조 패턴의 경우, 구조의 컴포넌트 기능성을 효율적으로 향상시키기 위해 객체를 좀 더 복잡한 구조로 ~~구성시킨다~~. ~~행위 패턴은~~ 시스템의 기능적 행위, 객체가 목표를 달성하기 위한 의사소통, 협력, 책임의 분산 방법을 다룬다.		'''디자인 패턴''' 에서와 마찬가지로 이 책은 생성 패턴, 구조 패턴, 행동 패턴의 세 장으로 구성된다. 생성 패턴에서는 객체의 생성 과정을 다룬다. 구조 패턴의 경우, 구조의 컴포넌트 기능성을 효율적으로 향상시키기 위해 객체를 좀 더 복잡한 구조로 구성하게 한다. 행동 패턴에서는 시스템의 기능적 행위, 객체가 목표를 달성하기 위한 의사소통, 협력, 책임의 분산 방법을 다룬다.

	다음으로는 패턴의 ''범위''~~(scope)~~에 따라 패턴 이름을 제목으로 ~~분류하여~~ 각 패턴을 주로 클래스에 적용하는지 아니면 인스턴스에 적용하는지를 ~~상세히~~ 다룬다. ~~클래스~~ 패턴은 ~~종속을~~ 통해 ~~구축된~~ 클래스 간의 정적 관계에 ~~초점을~~ 둔다. 객체 패턴은 인스턴스들 간 동적 런타임 관계를 ~~수반한다~~. 예를 들어, Template Method 패턴은 ~~그 구현이 종속과 메서드의 오버라이딩을~~ 통해 ~~시행되기 때문에~~ 클래스 ~~행위에~~ 분류된다. ~~슈퍼클래스는~~ 하나 또는 그 이상의 이차 메서드를 호출하는 넓은 범위의 메서드를 정의하며, ~~서브클래스는~~ 그에 종속된 메서드 일부 또는 전부를 오버라이드할 수 있다; 따라서 패턴의 컴포넌트는 모두 정적이며, 클래스를 기반으로 한다. Strategy 패턴은 객체 행위로 분류되는데, 그 이유는 Strategy 클래스의 정의에 종속을 포함하고 있음에도 불구하고 객체 간 상호작용이 패턴의 주요 ~~특성에~~ 포함되기 때문이다.		다음으로는 패턴의 ''범위<sup>scope</sup>''에 따라 패턴 이름을 제목으로 분류해서, 각 패턴을 주로 클래스에 적용하는지, 아니면 인스턴스에 적용하는지를 상세하게 다룬다. Class 패턴은 상속을 통해 설정된 클래스 간의 정적 관계에 중점을 둔다. Object 패턴은 인스턴스들 간 동적 런타임 관계를 포함한다. 예를 들어, Template Method 패턴은 상속과 메서드 재정의를 통해 구현되므로 클래스 동작으로 분류된다. 상위클래스는 하나 또는 그 이상의 이차 메서드를 호출하는 넓은 범위의 메서드를 정의하며, 하위클래스는 그에 종속된 메서드 일부 또는 전부를 오버라이드할 수 있다; 따라서 패턴의 컴포넌트는 모두 정적이며, 클래스를 기반으로 한다. Strategy 패턴은 객체 행위로 분류되는데, 그 이유는 Strategy 클래스의 정의에 종속을 포함하고 있음에도 불구하고 객체 간 상호작용이 패턴의 ''주요'' 특성으로 포함되기 때문이다.

	~~전체적 구조는~~ 동일하지만 이 책의 내용과 GoF 패턴의 ~~양식이~~ 완전히 중복되는 것은 아니다. 그렇다고 완전히 새로운 패턴을 작성하는 것도 ~~아니다; GoF가~~ 이미 쓴 패턴들이다. 대신 이러한 패턴들에 대한 ~~스몰토크~~ 버전을 제시하는 것이 목적이다. 따라서 GoF 패턴에 사용된 모든 ~~하위단락을 필요로 하진 않는다~~. 우리 패턴은 다음과 같이 변하기 쉬운 내용을 싣고 있다.		전체적인 구성은 동일하지만 이 책의 내용과 GoF 패턴의 형식이 완전히 중복되는 것은 아니다. 그렇다고 완전히 새로운 패턴을 작성하는 것도 아니며, GoF 가 이미 사용한 패턴들이다. 대신 이러한 패턴들에 대한 Smalltalk 버전을 제시하는 것이 우리의 목적이다. 따라서 GoF 패턴에 사용된 모든 하위단락이 필요한 것은 아니다. 이 책의 패턴은 다음과 같이 변하기 쉬운 내용을 싣고 있다.

	* ~~간단한~~ 의도 단락에서는 가끔씩 다른 말로 변경한 부분이 ~~있긴 하나~~ [디자인 패턴] 본문을 그대로 발췌하였다.		* '''의도<sup>intent</sup>''' 단락에서는 가끔씩 다른 말로 변경한 부분이 있지만, [디자인 패턴] 본문을 그대로 발췌하였다.
	* 패턴의 구조 다이어그램. 주로 '''디자인 패턴''' ~~다이어그램과~~ 다르다. 더 명확한 설명을 위해 많은 구조 다이어그램을 ~~수정하여 클래스~~ 객체 등 ~~스몰토크에~~ 요구되는 객체를 포함하거나 C++ 구현과 ~~패턴의 스몰토크~~ 버전을 반영하고자 하였다. 구조적으로는 동일할지 몰라도 C++가 아닌 ~~스몰토크~~ 구문과 의미론을 반영한다.		* 패턴의 '''구조<sup>Structure</sup>''' 다이어그램. 대부분 '''디자인 패턴''' 다이어그램과는 다르다. 더 명확한 설명을 위해 많은 구조 다이어그램을 수정했으며, Class 객체 등 Smalltalk 에 요구되는 객체를 포함하거나, C++ 의 구현과 패턴에 대한 Smalltalk 버전을 반영하고자 하였다. 구조적으로는 동일할지 몰라도 C++ 가 아닌 Smalltalk 구문과 의미론을 반영한다.
	* 논의 부분에서는 패턴의 동기, ~~스몰토크~~ 버전과 C++ 렌더링의 차이, 패턴의 장단점, 패턴을 ~~적용 시 고려해야 할 일반~~ 사항들과 같은 주제들을 ~~고려한다~~. 이 부분은 크리스토퍼 알렉산더의 ~~패턴과 같이~~ 일반적인 ~~설명식으로~~ 구성된다 (Alexander et al., 1977).		* '''논의<sup>Discussion</sup>''' 부분에서는 패턴의 동기, Smalltalk 버전과 C++ 렌더링의 차이, 패턴의 장단점, 패턴을 적용하려 할때 고민해야할 일반적인 사항들과 같은 주제들을 다룬다. 이 부분은 크리스토퍼 알렉산더의 패턴처럼 일반적인 설명으로 구성된다 (Alexander et al., 1977).
	* 협력 ~~패턴과~~ 활용성 단락은 선택적이며, 때로는 논의 부분에서 ~~다루기도~~ 한다.		* '''협력<sup>Collaborations</sup>''' 및 '''활용성<sup>Applicability</sup>''' 단락은 선택적이며, 때로는 논의 부분에서 다뤄지기도 한다.
	* 구현 ~~부분은 스몰토크~~ 또는 일반적으로 ~~패턴의 구현 시 관련된~~ 주제들을 ~~고려한다~~.		* '''구현<sup>Implementation</sup>''', Smalltalk 또는 일반적으로 패턴을 구현할때에 대한 관련 주제들을 다룬다.
	* 예제 코드 ~~부분에서는~~ 패턴을 사용하는 ~~스몰토크~~ 코드를 제공한다. 가끔 내용이나 흐름상 ~~적절할 경우~~ 구현과 예제 코드를 하나의 ~~단락에~~ 끼워 넣기도 한다.		* '''예제 코드<sup>Sample Code</sup>''' 에서는 패턴을 사용하는 Smalltalk 코드를 제공한다. 가끔 내용이나 흐름상 적절한 상황이라면, 구현과 예제 코드를 하나의 단락으로 끼워 넣기도 한다.
	* 알려진 ~~스몰토크~~ 사용예. 본 저서는 '''Smalltalk Companion'''이기 때문에 디자인 패턴을 사용하는 ~~스몰토크~~ 애플리케이션 및 ~~스몰토크~~ 라이브러리 클래스만 제시하는 것이 옳다고 판단하였다.		* '''알려진 Smalltalk 사용예<sup>Known Smalltalk Uses</sup>'''. 본 저서는 '''Smalltalk Companion''' 이기 때문에 디자인 패턴을 사용하는 Smalltalk 애플리케이션 및 Smalltalk 라이브러리 클래스만 제시하는 것이 옳다고 판단하였다.
	* 관련 패턴. 이 부분은 선택적이다. '''디자인 패턴'''에 언급된 내용으로 ~~충분하다면~~ 이 단락은 ~~건너 뛰어도 좋다~~.		* '''관련 패턴<sup>Related Patterns</sup>'''. 이 부분은 선택적이다. ''디자인 패턴''에 언급된 내용으로 충분한 경우라면, 이 단락은 없다.



			==Notes==
			<references />

	[[Category:DesignPatternSmalltalkCompanion]]		[[Category:DesignPatternSmalltalkCompanion]]

Onionmixer: 메소드 > 메서드 수정

2013-01-08T10:18:50Z

메소드 > 메서드 수정

← Older revision		Revision as of 10:18, 8 January 2013
Line 1:		Line 1:
	===1.4 우리의 패턴 논의===		===1.4 우리의 패턴 논의===

	GoF와 우리가 논하는 패턴들은 특정 추상 수준을 possess한다. 일반적으로 패턴은 객체지향 애플리케이션에서 서로 다른 입자도(granularity)와 추상화 수준에서 발생하며, 그 범위는 마이크로부터 매크로까지이다. ~~메소드의~~ 변수를 어떻게 명칭을 할 것인지, 지연 초기화를 어떻게 구현할 것인지, 코드를 어떻게 포맷할 것인지와 저수준 문제들에 대한 규약은 마이크로패턴으로 간주한다 (Kent Beck의 ''Smalltalk Best Practice Pattern [1997b]''에 나오는 패턴의 다수는 이 범주에 속한다). 그 반대로 VisualWorks의 대화형 애플리케이션에 매우 중요한 아키텍처인 Model-View-Controller 프레임워크는 매크로패턴에 속한다. Buschmann et al.(1996)은 전체적으로 패턴을 ''용어''부터 ''디자인 패턴''까지, 그리고 ''아키텍처 패턴''까지의 범위를 가진다고 주장한다. 우리 디자인 패턴들은 핵심 분야에 중점을 둔다. 이 패턴들은 잘 고안되고 프로그램화된 애플리케이션들의 일부에 유용한 마이크로아키텍처의 구조와 구현을 설명한다.		GoF와 우리가 논하는 패턴들은 특정 추상 수준을 possess한다. 일반적으로 패턴은 객체지향 애플리케이션에서 서로 다른 입자도(granularity)와 추상화 수준에서 발생하며, 그 범위는 마이크로부터 매크로까지이다. 메서드의 변수를 어떻게 명칭을 할 것인지, 지연 초기화를 어떻게 구현할 것인지, 코드를 어떻게 포맷할 것인지와 저수준 문제들에 대한 규약은 마이크로패턴으로 간주한다 (Kent Beck의 ''Smalltalk Best Practice Pattern [1997b]''에 나오는 패턴의 다수는 이 범주에 속한다). 그 반대로 VisualWorks의 대화형 애플리케이션에 매우 중요한 아키텍처인 Model-View-Controller 프레임워크는 매크로패턴에 속한다. Buschmann et al.(1996)은 전체적으로 패턴을 ''용어''부터 ''디자인 패턴''까지, 그리고 ''아키텍처 패턴''까지의 범위를 가진다고 주장한다. 우리 디자인 패턴들은 핵심 분야에 중점을 둔다. 이 패턴들은 잘 고안되고 프로그램화된 애플리케이션들의 일부에 유용한 마이크로아키텍처의 구조와 구현을 설명한다.

	'''디자인 패턴'''에서와 마찬가지로 이 책은 생성 패턴, 구조 패턴, 행위 패턴의 세 장으로 구성된다. 생성 패턴에는 객체의 생성 과정을 다룬다. 구조 패턴의 경우, 구조의 컴포넌트 기능성을 효율적으로 향상시키기 위해 객체를 좀 더 복잡한 구조로 구성시킨다. 행위 패턴은 시스템의 기능적 행위, 객체가 목표를 달성하기 위한 의사소통, 협력, 책임의 분산 방법을 다룬다.		'''디자인 패턴'''에서와 마찬가지로 이 책은 생성 패턴, 구조 패턴, 행위 패턴의 세 장으로 구성된다. 생성 패턴에는 객체의 생성 과정을 다룬다. 구조 패턴의 경우, 구조의 컴포넌트 기능성을 효율적으로 향상시키기 위해 객체를 좀 더 복잡한 구조로 구성시킨다. 행위 패턴은 시스템의 기능적 행위, 객체가 목표를 달성하기 위한 의사소통, 협력, 책임의 분산 방법을 다룬다.

	다음으로는 패턴의 ''범위''(scope)에 따라 패턴 이름을 제목으로 분류하여 각 패턴을 주로 클래스에 적용하는지 아니면 인스턴스에 적용하는지를 상세히 다룬다. 클래스 패턴은 종속을 통해 구축된 클래스 간의 정적 관계에 초점을 둔다. 객체 패턴은 인스턴스들 간 동적 런타임 관계를 수반한다. 예를 들어, Template Method 패턴은 그 구현이 종속과 ~~메소드의~~ 오버라이딩을 통해 시행되기 때문에 클래스 행위에 분류된다. 슈퍼클래스는 하나 또는 그 이상의 이차 ~~메소드를~~ 호출하는 넓은 범위의 ~~메소드를~~ 정의하며, 서브클래스는 그에 종속된 ~~메소드~~ 일부 또는 전부를 오버라이드할 수 있다; 따라서 패턴의 컴포넌트는 모두 정적이며, 클래스를 기반으로 한다. Strategy 패턴은 객체 행위로 분류되는데, 그 이유는 Strategy 클래스의 정의에 종속을 포함하고 있음에도 불구하고 객체 간 상호작용이 패턴의 주요 특성에 포함되기 때문이다.		다음으로는 패턴의 ''범위''(scope)에 따라 패턴 이름을 제목으로 분류하여 각 패턴을 주로 클래스에 적용하는지 아니면 인스턴스에 적용하는지를 상세히 다룬다. 클래스 패턴은 종속을 통해 구축된 클래스 간의 정적 관계에 초점을 둔다. 객체 패턴은 인스턴스들 간 동적 런타임 관계를 수반한다. 예를 들어, Template Method 패턴은 그 구현이 종속과 메서드의 오버라이딩을 통해 시행되기 때문에 클래스 행위에 분류된다. 슈퍼클래스는 하나 또는 그 이상의 이차 메서드를 호출하는 넓은 범위의 메서드를 정의하며, 서브클래스는 그에 종속된 메서드 일부 또는 전부를 오버라이드할 수 있다; 따라서 패턴의 컴포넌트는 모두 정적이며, 클래스를 기반으로 한다. Strategy 패턴은 객체 행위로 분류되는데, 그 이유는 Strategy 클래스의 정의에 종속을 포함하고 있음에도 불구하고 객체 간 상호작용이 패턴의 주요 특성에 포함되기 때문이다.

	전체적 구조는 동일하지만 이 책의 내용과 GoF 패턴의 양식이 완전히 중복되는 것은 아니다. 그렇다고 완전히 새로운 패턴을 작성하는 것도 아니다; GoF가 이미 쓴 패턴들이다. 대신 이러한 패턴들에 대한 스몰토크 버전을 제시하는 것이 목적이다. 따라서 GoF 패턴에 사용된 모든 하위단락을 필요로 하진 않는다. 우리 패턴은 다음과 같이 변하기 쉬운 내용을 싣고 있다.		전체적 구조는 동일하지만 이 책의 내용과 GoF 패턴의 양식이 완전히 중복되는 것은 아니다. 그렇다고 완전히 새로운 패턴을 작성하는 것도 아니다; GoF가 이미 쓴 패턴들이다. 대신 이러한 패턴들에 대한 스몰토크 버전을 제시하는 것이 목적이다. 따라서 GoF 패턴에 사용된 모든 하위단락을 필요로 하진 않는다. 우리 패턴은 다음과 같이 변하기 쉬운 내용을 싣고 있다.
Line 17:		Line 17:
	* 알려진 스몰토크 사용예. 본 저서는 '''Smalltalk Companion'''이기 때문에 디자인 패턴을 사용하는 스몰토크 애플리케이션 및 스몰토크 라이브러리 클래스만 제시하는 것이 옳다고 판단하였다.		* 알려진 스몰토크 사용예. 본 저서는 '''Smalltalk Companion'''이기 때문에 디자인 패턴을 사용하는 스몰토크 애플리케이션 및 스몰토크 라이브러리 클래스만 제시하는 것이 옳다고 판단하였다.
	* 관련 패턴. 이 부분은 선택적이다. '''디자인 패턴'''에 언급된 내용으로 충분하다면 이 단락은 건너 뛰어도 좋다.		* 관련 패턴. 이 부분은 선택적이다. '''디자인 패턴'''에 언급된 내용으로 충분하다면 이 단락은 건너 뛰어도 좋다.

	[[Category:DesignPatternSmalltalkCompanion]]		[[Category:DesignPatternSmalltalkCompanion]]

Onionmixer: DPSC 우리의패턴논의 페이지 추가

2012-07-26T12:37:38Z

DPSC 우리의패턴논의 페이지 추가

New page

===1.4 우리의 패턴 논의===

GoF와 우리가 논하는 패턴들은 특정 추상 수준을 possess한다. 일반적으로 패턴은 객체지향 애플리케이션에서 서로 다른 입자도(granularity)와 추상화 수준에서 발생하며, 그 범위는 마이크로부터 매크로까지이다. 메소드의 변수를 어떻게 명칭을 할 것인지, 지연 초기화를 어떻게 구현할 것인지, 코드를 어떻게 포맷할 것인지와 저수준 문제들에 대한 규약은 마이크로패턴으로 간주한다 (Kent Beck의 ''Smalltalk Best Practice Pattern [1997b]''에 나오는 패턴의 다수는 이 범주에 속한다). 그 반대로 VisualWorks의 대화형 애플리케이션에 매우 중요한 아키텍처인 Model-View-Controller 프레임워크는 매크로패턴에 속한다. Buschmann et al.(1996)은 전체적으로 패턴을 ''용어''부터 ''디자인 패턴''까지, 그리고 ''아키텍처 패턴''까지의 범위를 가진다고 주장한다. 우리 디자인 패턴들은 핵심 분야에 중점을 둔다. 이 패턴들은 잘 고안되고 프로그램화된 애플리케이션들의 일부에 유용한 마이크로아키텍처의 구조와 구현을 설명한다.

'''디자인 패턴'''에서와 마찬가지로 이 책은 생성 패턴, 구조 패턴, 행위 패턴의 세 장으로 구성된다. 생성 패턴에는 객체의 생성 과정을 다룬다. 구조 패턴의 경우, 구조의 컴포넌트 기능성을 효율적으로 향상시키기 위해 객체를 좀 더 복잡한 구조로 구성시킨다. 행위 패턴은 시스템의 기능적 행위, 객체가 목표를 달성하기 위한 의사소통, 협력, 책임의 분산 방법을 다룬다.

다음으로는 패턴의 ''범위''(scope)에 따라 패턴 이름을 제목으로 분류하여 각 패턴을 주로 클래스에 적용하는지 아니면 인스턴스에 적용하는지를 상세히 다룬다. 클래스 패턴은 종속을 통해 구축된 클래스 간의 정적 관계에 초점을 둔다. 객체 패턴은 인스턴스들 간 동적 런타임 관계를 수반한다. 예를 들어, Template Method 패턴은 그 구현이 종속과 메소드의 오버라이딩을 통해 시행되기 때문에 클래스 행위에 분류된다. 슈퍼클래스는 하나 또는 그 이상의 이차 메소드를 호출하는 넓은 범위의 메소드를 정의하며, 서브클래스는 그에 종속된 메소드 일부 또는 전부를 오버라이드할 수 있다; 따라서 패턴의 컴포넌트는 모두 정적이며, 클래스를 기반으로 한다. Strategy 패턴은 객체 행위로 분류되는데, 그 이유는 Strategy 클래스의 정의에 종속을 포함하고 있음에도 불구하고 객체 간 상호작용이 패턴의 주요 특성에 포함되기 때문이다.

전체적 구조는 동일하지만 이 책의 내용과 GoF 패턴의 양식이 완전히 중복되는 것은 아니다. 그렇다고 완전히 새로운 패턴을 작성하는 것도 아니다; GoF가 이미 쓴 패턴들이다. 대신 이러한 패턴들에 대한 스몰토크 버전을 제시하는 것이 목적이다. 따라서 GoF 패턴에 사용된 모든 하위단락을 필요로 하진 않는다. 우리 패턴은 다음과 같이 변하기 쉬운 내용을 싣고 있다.

* 간단한 의도 단락에서는 가끔씩 다른 말로 변경한 부분이 있긴 하나 [디자인 패턴] 본문을 그대로 발췌하였다.
* 패턴의 구조 다이어그램. 주로 '''디자인 패턴''' 다이어그램과 다르다. 더 명확한 설명을 위해 많은 구조 다이어그램을 수정하여 클래스 객체 등 스몰토크에 요구되는 객체를 포함하거나 C++ 구현과 패턴의 스몰토크 버전을 반영하고자 하였다. 구조적으로는 동일할지 몰라도 C++가 아닌 스몰토크 구문과 의미론을 반영한다.
* 논의 부분에서는 패턴의 동기, 스몰토크 버전과 C++ 렌더링의 차이, 패턴의 장단점, 패턴을 적용 시 고려해야 할 일반 사항들과 같은 주제들을 고려한다. 이 부분은 크리스토퍼 알렉산더의 패턴과 같이 일반적인 설명식으로 구성된다 (Alexander et al., 1977).
* 협력 패턴과 활용성 단락은 선택적이며, 때로는 논의 부분에서 다루기도 한다.
* 구현 부분은 스몰토크 또는 일반적으로 패턴의 구현 시 관련된 주제들을 고려한다.
* 예제 코드 부분에서는 패턴을 사용하는 스몰토크 코드를 제공한다. 가끔 내용이나 흐름상 적절할 경우 구현과 예제 코드를 하나의 단락에 끼워 넣기도 한다.
* 알려진 스몰토크 사용예. 본 저서는 '''Smalltalk Companion'''이기 때문에 디자인 패턴을 사용하는 스몰토크 애플리케이션 및 스몰토크 라이브러리 클래스만 제시하는 것이 옳다고 판단하였다.
* 관련 패턴. 이 부분은 선택적이다. '''디자인 패턴'''에 언급된 내용으로 충분하다면 이 단락은 건너 뛰어도 좋다.
[[Category:DesignPatternSmalltalkCompanion]]