Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!gatech!news.sprintlink.net!mv!usenet
From: rapp@lmr.com (L. M. Rappaport)
Subject: Re: What EXACTLY is Design Patterns -- HELP --
Message-ID: <DDIG2L.9qw@mv.mv.com>
Nntp-Posting-Host: lmr.com
Sender: usenet@mv.mv.com (System Administrator)
Organization: MV Communications, Inc.
Date: Fri, 18 Aug 1995 17:22:03 GMT
References: <40vmqc$lmf@crchh327.rich.bnr.ca>
X-Newsreader: Forte Free Agent 1.0.82
Lines: 63

vanchau@bnr.ca (Vanchau Nguyen) wrote:

>	Can someone tell me exactly what is meant by a design pattern?

>	If I had to guess, I would think it was a way to model the 
>system you are working on.  I guess that some people discovered a
>lot of real life problems have similar attributes, and therefore,
>this is where patterns occur.  Due to these 'patterns', one may
>use a similar design for this new problem that was used in a
>previous one.

I'm not an expert, just a beginner like yourself, but I have read two
of the more popular books on the subject, which gives me just enough
knowlege to be dangerous.  :)

Your guess is close - patterns certainly could apply to an entire
system model, but they usually deal with a smaller domain.  In the
"Design Patterns" book by Gamma et al, patterns are divided into three
categories: creational, structural and behavioral.  An example of a
creational pattern is the "singleton" which provides a solution for
the problem of what do you do when you want to ensure that a class has
only "one instance and provide a global point of access to it".  The
"pattern" provided in this case is a generic solution which you could
use whenever you recognize the problem.  Likewise a common structural
pattern is the "Adapter", where you wish to convert the interface of
one class to the different interface expected by another class.  A
useful behavioral pattern is the "Iterator" which decouples the method
of access from the structure of a collection, so that it becomes easy
to change the collection class without having to re-write a bunch of
code.  (more useful in C++ than Smalltalk where the better class
libraries implement a better polymorphic interface to collections)

The Pree book is more theorectical concerning itself  with naming
patterns and meta-patterns which help you build usable frameworks.

In any case, patterns are really generic solutions to problems.  Once
you master them, you can look at a problem in their terms and come up
with the "Aha!  That's a singleton problem, I know how to solve it"
Patterns exist in all languages and all methodologies, just that they
are (or seem to me to be) easier to apply in object-oriented
languages.

If you're interested in reading more, try:

  "Design Patterns - Elements of Reusable Object-Oriented Software" by
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison
Wesley 1995 ISBN 0-201-63361-2

 "Design Patterns for Object-Oriented Software Development" by
Wolfgang Pree, Addison Wesley 1994 ISBN 0-201-42294-8

  The first book presents many specific patterns along with a
discussion of various solutions.  Code is presented in both C++ and
Smalltalk.  It is more algorithmic and specific than the Pree book
which is more theoretical and which has a wider range (Pree deals with
such issues as coding patterns, basic interaction patterns, naming
conventions, formal contracts, etc.)  It supports a free language
known as ET++ which is created from C++.  Still, many of the concepts
are eminently useful to a Smalltalk programmer.

Larry
--

