1. Chapter 1 ¶

1.1. Introduction ¶

p1

Welcome to The Design Patterns Smalltalk Companion , a companion volume to Design Patterns Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and Jogn Vlissides(Gamma, 1995). While the earlier book was not the first publication on design patterns, it has fostered a minor revolution in the software engineering world.Designers are now speaking in the language of design patterns, and we have seen a proliferation of workshops, publications, and World Wide Web sites concerning design patterns. Design patterns are now a dominant theme in object-oriented programming research and development, and a new design patterns community has emerged.

The Design Patterns Smalltalk Companion �� 환��합��. �� Design Patterns Elements of Reusable Object-Oriented Software(��하 DP) Erich Gamma, Richard Helm, Ralph Johnson, and Jogn Vlissides(Gamma, 1995). �� 편��(companion, �� 편��하�� 하�� ) ��. �� (DP)�� 패�� 한 �� , DP�� 트�� 혁�� . �� 패�� 하��, �� 패�� 한 �� workshop, ��판��, �� 트�� 폭팔�� . �� 패�� 향 �� 한 �� , �� 패�� 티�� 하�� .(emerge �� come up or out into view �� come to light �� 해��하�� . �� 패�� 향 �� 한 �� , �� 패�� 티�� 하�� . �� 하��. -_-; -- �� ? -�� -- DeleteMe)gogo..~ �� 하��, �� 합��.

Design Patterns describes 23 design patterns for applications implemented in an object-oriented programming language. Of course, these 23 patterns do not capture all the design knowledge an object-oriented designer will ever need. Nonetheless, the patterns from the "Gang of Four"(Gamma et al.) are a well-founded starting point. They are a design-level analog to the base class libraries found in Smalltalk development environments. They do not solve all problems but provide a foundation for learning environments. They do not solve all problems but provide a foundation for learning about design patterns in general and finding specific useful architectures that can be incorporated into the solutions for a wide variety of real-world design problems. They capture an expert level of design knowledge and provide the foundation required for building elegant, maintainable, extensible object-oriented programs.

�� 패���� 향 �� 23�� 패�� 합��. ��, 23�� 패�� 향 �� 할 �� 합��. �� 하�� "Gang of Four"(Gamma et al.)�� 한 23�� 패�� 한 �� 합��. �� 23�� 패�� Smalltalk class libraries�� 한 �� (design-level) ��(analog)��. �� 패�� 해�� 해��할 �� , ��, �� 한 �� 한 해�� 한 ��한 �� 할��. ��, �� 패�� 통해�� 하��, ��하��, �� 편하��, 확��하�� 향 �� 하�� 톡톡한 ��할�� 할��.

In the Smalltalk Companion, we do not add to this "base library" of patterns;rather, we present them for the Smalltalk designer and programmer, at times interpreting and expanding on the patterns where this special perspective demands it. Our goal is not to replace Design Patterns; you should read the Smalltalk Companion with Design Patterns, not instead of it. We have tried not to repeat information that is already well documented by the Gang of Four book. Instead, we refer to it requently;you should too.

Smalltalk Companion��, �� 패�� "base library"�� 하�� 패�� 확��하�� 해��해��, �� 해 ��한��.
�� Design Pattern�� 하�� . �� Design Pattern�� 하�� Design Pattern�� 함�� Smalltalk Companion�� 한��.
�� Gang of Four �� 화�� 해�� 하�� . ��, �� 해��한��. �� 한 �� 해��한��.

Another)
Smalltalk Companion��, �� 패�� 'base library'�� 하�� . ��, �� base library�� Smalltalk �� 해��하�� ?灌? 확��하�� Smalltalk �� 해 ��할 ��. �� 표�� Design Patterns�� 하�� . Design Patterns �� Smalltalk Companion�� 하�� , �� . �� Gang of Four�� 화�� 하�� . ��, �� GoF�� 할 ��, �� 할 ��. -- �� .. ��

1.2. 1.1 Why Design Patterns? ¶

Learning an object-oriented language after programming in another paradigm, such as the traditional procedural style, is difficult. Learning to program and compose application in Smalltalk requires a complex set of new skills and new ways of thinking about problems(e.g Rosson & Carroll, 1990; Singley, & Alpert, 1991). Climbing the "Smalltalk Mountain" learning curve is cetainly nontrivial. Once you have reached that plateau where you feel comfortable building simple Smalltalk applications, there is still a significant distance to the expert peak.

�� 테�� (��통�� )�� 한 �� 향 �� . Smalltalk �� 합�� 하�� 한 �� 한 �� 한��.(" e.g Rosson & Carroll, 1990; Singley, & Alpert, 1991") "Smalltalk" �� 확��히 ��한 �� . �� 한 Smalltalk �� 해��, �� 한 �� .

Smalltalk experts know many things that novices do not, at various abstraction levels and across a wide spectrum of programming and design knowledge and skills:

The low-level details of the syntax and semantics of the Smalltalk language
What is available in the form of classes, methods, and functionality in the existing base class libraries
How to use the specific tools of the Smalltalk interactive development environment to find and reuse existing functionality for new problems, as well as understanding programs from both static and runtime perspective
How to define and implement behavior in new classes and where these classes ought to reside in the existing class hierarchy
Which classes work well together as frameworks
Recurring patterns of object configurations and interactions and the sorts of problems for which these cooperating objects provide (at least partial) solutions

Smalltalk �� 한 �� 폭�� programming�� design�� 한 �� 하�� .

Smalltalk�� 호�� (��퓨�� low-level ��)�� 항�� 해
��하�� class �� 한 class, methods. �� (�� functionality�� function �� 해��. 태클 ��. --;)�� 해
�� 해�� 한 �� 하�� 해, �� 해하�� 해 �� Smalltalk IDE 툴�� 해�� 하�� 해
�� 클�� frameworks�� 하�� 해
�� 환�� 호��, ��한 �� 협��하�� 해��해��할 �� 패�� 해

This is by no means an exhaustive list, and even novices understand and use much of the knowledge. But some items, especially the last -- recurring patterns of software design, or design patterns -- are the province of design expert.

A design pattern is a reusable implementation model or architecture that can be applied to solve a particular recurring class of problem. The pattern sometimes describes how methods in a single class or subhierarchy of classes work together; more often, it shows how multiple classes and their instances collaborate. It turns out that particular architectures reappear in different applications and systems to the extent that a generic pattern template emerges, one that experts reapply and customize to new application - and domain-specific problems. Hence, experts know how to apply design patterns to new problems to implement elegant and extensible solutions.

�� 패���� 하�� 클�� 해�� 하�� 할�� 행 �� 키텍��. �� 패�� 하�� 클�� 함�� 하�� 한��.; ��, 패�� 히 �� 클�� 협�� .

패�� 플�� 템�� 한(��한, 플�� ) ��키택��, �� 플��,�� 하�� 한 �� 한��. (�� one�� particular architecture�� 한 �� 해��한 ��. �� -��

��, �� 하�� 하�� 확�� 해�� 하�� 패�� 활�� .
(��, �� 해��하�� 해 ��하�� 확�� 패�� 하�� .)

In general, designers -- in numerous domains, not just software -- apply their experience with past problems and solution to new, similar problems. As Duego and Benson(1996) point out, expert designers apply what is known in cognitive psychology and artificial intelligence as case-based reasoning, remembering past cases and applying what they learned there. This is the sort of reasoning that chess masters, doctors, lawyers, and architects empoly to solve new problems. Now, design patterns allow software designers to learn from and apply the experiences of other designers as well. As in other domains, a literature of proven patterns has emerged. As a result, we can "stand on the shoulders of giants" to get us closer to the expert peak. As John Vlissies (1997) asserts, design patterns "capture expertise and make it accessible to non-experts" (p. 32).

��-��트�� 한하�� -�� , 해�� 험�� 한 �� 킨��. Duego�� Genson(1996)�� 험�� 한 ��혜�� 하�� 키�� 한��. (�� ) �� , ��, ��호�� 하�� 한 ��. ��, �� 패�� 트�� (other designer)�� 험�� 한��. �� , "�� " �� 훌��한 �� . John Vlissies(1997)�� 패�� "�� 하�� 해�� 평한��. (p. 32).

Design patterns also provide a succinct vocabulary with which to describe new designs and retrospectively explain existing ones. Patterns let us understand a design at a high level before drilling down to focus on details. They allow us to envision entire configurations of objects and classes at a large grain size and communicate these ideas to other designers by name. We can say, "Implement the database access object as a Singleton," rather than, "Let's make sure the database access class has just one instance. The class should include a class variable to keep track of the singl instance. The class should make the instance globally available but control access to it. The class should control when the instance is created and ..." Which would you prefer?

�� 패�� 패�� 해�� 하�� 표��하��, 패�� 하�� 히 ��한��.패�� , �� 큰 �� 해�� 할�� 한��. 패�� 큰 �� 환�� 클�� 한��. �� "�� 했��." �� "�� 하�� 하�� 해��. �� 클�� 해�� 클�� 할��. �� 클�� 한 �� , ��
�� 클�� ... "�� 할�� . �� 하��?

��.. --; �� 하�� -- ��

1.3. 1.2 Why a Smalltalk Companion? ¶

p3 ��

Christopher Alexander and his colleagues have written extensively on the use of design patterns for living and working spaces-homes, buildings, communal areas, towns. Their work is considered the inspiration for the notion of software design patterns. In The Timeless Way of Building(1979) Alexander asserts, "Sometimes there are version of the same pattern, slightly different, in different cultures" (p.276). C++ and Smalltalk are different languages, different environments, different cultures-although the same basic pattern may be viable in both languages, each culture may give rise to different versions.

Christopher Alexander�� , �� 패�� 활��, ��, �� 확�� 한 �� . �� 하�� 통하��, ��트�� 패�� 한 �� , �� 한 �� (��)��. The Timeless Way of Building(1979) ��?? Alexander�� "�� 화�� 패�� 하�� "(p.276) �� 한��. C++�� Samlltalk�� 패�� 해�� , �� 환��, �� 화�� .

The Gang of Four's Design Patterns presents design issues and solutions from a C+ perspective. It illustrates patterns for the most part with C++ code and considers issues germane to a C++ implementation. Those issue are important for C++ developres, but they also make the patterns more difficult to understand and apply for developers using other languages.

Gang of Four�� Design Patterns �� C++�� 해�� 한��. Design Patterns�� C++�� 한 패��, C++�� (implementation)�� 한 ��해�� . ��한 �� C++ �� 할�� , �� 하�� 해하�� 패�� .

This book is designed to be a companion to Design Patterns, but one written from the Smalltalk perspective. One way to think of the Smalltalk Companion, then, is as a variation on a theme. We provide the same pattern as in the Gang of Four book but view them through Smalltalk glasses. (In fact, when we were trying out names for the Smalltalk Companion, someone suggested "DesignPattern asSmalltalkCompanion." However, we decided only hard-core Smalltalkers would get it.)

�� Design Patterns �� 한 ��, 편�� . 하�� Design Pattern�� C++�� 하�� Smalltalk�� 한��. ��, �� Smalltalk Companion�� 해�� 하�� (design pattern)�� 한 ��한 �� 해 �� 한��. �� Gang of Four book�� 패�� 하��, Smalltalk�� 통해�� . (��, �� Samlltalk Companion�� "DesignPattern asSmalltalkCompanion" ��-�� Smalltalk�� 표�� .- ��하�� 했��. 하�� hard-core Smalltalkers�� 했��.)

p 3 1.2�� 합��. --��

But the Smalltalk Companion goes beyond merely replicating the text of Design Patterns and plugging in Smalltalk examples whereever C++ appeared. As a result, there are numerous situations where we felt the need for additional analysis, clarification, or even minor disagreement with the original patterns. Thus, many of our discussions should apply to other object-oriented languages as well.

하�� Smalltalk Companion�� Design Patterns �� 하�� 하�� C++ �� Smalltalk �� . ��, �� , ��, �� 패�� 한 �� 하�� 황�� . ��, �� 토�� 향 �� 할 ��.

Of course, we provide plenty of sample code in Smalltalk. Our examples are, for the most part, not simply Smalltalk versions of the Design Patterns examples. We often felt an alternative would be more useful than a mere translation of the C++ example.
Here in a nutshell are our goals for the Smalltalk Companion as a supplement to Design Patterns :

Discussion of issues specific to Smalltalk implementions of the Gang of Four's design patterns
Much more Smalltalk sample code
More Smalltalk known uses, especially from the major Smalltalk envirnoments class libraries
Exploring variations the patterns can embody in Smalltalk and in general
Many new examples, from application domains(insurance, telecommunications, etc.) and systems development (windowing systems, compilers, etc.)

��, �� Smalltalk�� 한 �� 한��. ��, �� Design Patterns �� 한 Smalltalk �� . �� C++ �� 한 �� 하�� . �� 한 �� Design Patterns�� 한 Smalltalk Companion�� 한 �� .

Gang of Four's design patterns�� Smalltalk �� 한 ��?��岵? �� 토�� 한��.
Smalltalk �� .
Smalltalk�� 한��. ��히 ��한 Smalltalk 환�� class libraries�� .
Smalltalk�� 화�� 패�� 화�� 탐험하��.
�� (��험, ��향 통��, ��.) �� 템 ��(�� 템, ��파��, ��.)�� .

1.4. 1.3 C++ != Smalltalk(or, Smalltalk ~= C++) ¶

DesignPatternSmalltalkCompanion

DPSC Chapter1

Contents

1. Chapter 1 ¶

1.1. Introduction ¶

1.2. 1.1 Why Design Patterns? ¶

1.3. 1.2 Why a Smalltalk Companion? ¶

1.4. 1.3 C++ != Smalltalk(or, Smalltalk ~= C++) ¶