A Sip From The Firehose: May 15, 1996

By: David Intersimone

Abstract: I'm back in the states, recovered from jet lag and back at work. After days spent in planes, airports, hotels and meetings I look forward to getting back to my family, home and work.

Wednesday, May 15, 1996
Scotts Valley, California

I'm back in the states, recovered from jet lag and back at work. After days spent in planes, airports, hotels and meetings I look forward to getting back to my family, home and work. A few hours after take-off from London Heathrow Airport and what seems like endless miles of ocean and clouds, I look out the window and suddenly the skies clear. Laid out before me are the towering mountains, winding glaciers and pristine snow-filled valleys of Greenland. Looking at the architecture of the Greenland landscape and the patterns of rock and ice always inspires me to think about our world, life, and of course developers.

While on the plane I read the program for the upcoming OOPSLA '96 (The Eleventh Annual ACM Conference on Object-Oriented Programming Systems, Languages and Applications) Conference (October 6-10 in San Jose, CA http://www.acm.org/sigplan/oopsla). I noticed with excitement that the opening session for the conference is an invited talk by Christopher Alexander. What does a professor at UC Berkeley with a Ph.D. in architecture named Christopher Alexander have to do with object-oriented software development?

Why have notable object methodologists, academics, consultants and software designers (Kent Beck, Grady Booch, Peter Coad, Ralph Johnson, Bruce Anderson, Jim Coplien, Ward Cunningham, and Erich Gamma to name just a few) referred to an obscure architectural design book The Timeless Way of Building (Oxford University Press, 1979, ISBN 0-19-502402-8) and its companion A Pattern Language (University Press, ISBN 0-19-501-919-9)? Why am I so excited? Why ask why?

Many developers are faced with the common aspects of software development: how to capture the design of the software, how to document the design and the best use of the software, how to avoid the mistakes that are only learned by experience, how to create a language that allows developers to communicate effectively and efficiently, how to capture software development expertise, and how to repeat the development success time and time again.

Current object methodologies are very useful for the specification, documentation and implementation of a design. I can show you the architecture of an application framework like OWL in a class hierarchy diagram and also point to the documentation that lists all the classes, methods and examples of its use. How can we also capture and communicate the original framework designer's ideas, thoughts, processes, decisions, constraints, tradeoffs, maintenance issues, advice, worries, and experience? Some very exciting work being done by some of the best in our industry in the area of Patterns portends an exciting revolution in the design, documentation and building of future applications and reusable components.

Kent Beck was the first to recognized the link between patterns and software engineering. He then convinced Ward Cunningham to get involved in 1987 while they were both consulting for Tektronix. Ward Cunningham wrote the first patterns for the user interface design of a semiconductor tester. If you are interested in more of the history of patterns and how they came to the world of software, Jim Coplien author of Advanced C++ Programming Styles and Idioms (Addison-Wesley, ISBN 0-201-54855-0) has written a first draft of the History of Patterns (http://c2.com/cgi-bin/wiki?HistoryOfPatterns).

To keep up to date on the Patterns movement, there are many books, articles, conferences and even a world wide web home page for the work being done in the area of software patterns and pattern languages (http://st-www.cs.uiuc.edu/users/patterns/patterns.html). The home page contains loads of information, references and hyperlinks. Quoting from the Patterns home page "Patterns and Pattern Languages are ways to describe best practices, good designs, and capture experience in a way that it is possible for others to reuse this experience".

What is a pattern? From the Patterns Discussion FAQ (http://g.oswego.edu/dl/pd-FAQ/pd-FAQ.html) "Why isn't there a good definition of 'pattern'?" comes the answer "Why isn't there a good definition of most engineering terms? 'Pattern' seems on at least as good footing as, say 'object'. No one seems to mind the short slogan 'a solution to a problem in a context'".

From the same FAQ comes the question "What's the best format for patterns?" -- and the answer offered is that there are several different styles of patterns but that most use something close to Alexander's original format:

IF you find yourself in CONTEXT
for example EXAMPLES,
with PROBLEM,
entailing FORCES
THEN for some REASONS
apply DESIGN FORM AND/OR RULE
to construct SOLUTION
leading to NEW CONTEXT and OTHER PATTERNS

To quote Kent Beck (from a Writing Patterns workshop I took at OOPSLA '94 in Portland OR) "Patterns are a literary form". When writing down patterns Kent suggests that you use the following sections:

  1. Title - used as a mental index. "Poems have titles not names"
  2. Problem - a question about some design decision. "How do I implement a state object?" "How big should a method be?"
  3. Constraints - talks about the forces working on the pattern. This section takes the reader through the though processes, the alternatives. "What am I worried about?"
  4. Solution - the actual implementation, the external protocol. This section contains something that you do. "create these classes, connect these nodes, perform these transformations". This section includes diagrams and descriptive text for the implementation.
  5. Example - in practice what does the use of the pattern look like. This section includes source code
  6. Related patterns - where to go from here. What other patterns are available. This is like a "see also" section in documentation and help files.

You can see more of Kent Beck's work with patterns via http://c2.com/cgi/wiki?KentBeck.

A few more questions and answers from the Patterns FAQ include: "What's the difference between a pattern and a framework? A framework is not a pattern, but may have been built using patterns. Also, the use of the framework may be described via patterns."; "What's the difference between a set of patterns and a style guide? While it might be possible to structure style guides as sets of patterns, none of them do. In particular, style guides typically omit descriptions about how to construct solutions."; and "What's the difference between a pattern and a programming idiom? A pattern can characterize an idiom, along with descriptions of how, when, and why to use it.".

What are some examples of patterns? A couple of patterns presented in the book Design Patterns by Gamma, Helm, Johnson, and Vlissides (Addison-Wesley, ISBN 0-201-63361-2) are: BRIDGE -- de-couple an abstraction from its implementation so that the two can vary independently; OBSERVER -- define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically; and VISITOR -- Represent and operation to be performed on the elements of an object structure, visitor lets you define a new operation without changing the classes of the elements on which it operates. There are also many examples of patterns available on the Web. A great place to look at different patterns is the Portland Pattern Repository maintained by Ward Cunningham at http://c2.com/ppr/index.html.

For more information about patterns with many practical examples you should check out the book Object Models Strategies, Patterns and Applications by Peter Coad with David North and Mark Mayfield (Yourdon Press, ISBN 0-13-108614-6). Some of you may remember that Peter has been a speaker at previous Borland Developer Conferences. Peter will again speak at our Seventh Annual Borland Developer Conference in Anaheim CA, July 27-31. More information about this conference is available on our Borland Web Site.

There is also a book based on papers presented at the First Annual Conference of Pattern Languages of Programs (PLoP) held in August 1994 called Pattern Languages of Program Design edited by Jim Coplien and Douglas Schmidt (Addison-Wesley, ISBN 0-201-60734-4). Plop '96 will be held in Allerton Park, Illinois, Sept. 4-6 and EuroPLoP '96 will be held in Kloster Irsee, Germany, July 11-13. For more information check out the PLoP '96 Call for Papers via http://www.cs.wustl.edu/~schmidt/jointPLoP-96.html.

In my humble opinion every class and component library developed should include a pattern language!!! The language would give developers guidance about how the library developer intended the library to be reused, would give insights into design decisions that the designer made, and would promote faster learning and a better understanding of the library architecture.

Just as Greenland's repeating glacial patterns and mountainous architecture stretch forever, I could go on an on about patterns and pattern languages and still only scratch the surface. Fortunately, there are already so many resources available in print and on the web that it's easy to get started. Start reading about patterns today, start using patterns today, and start writing patterns as soon as you can.

David Intersimone
(davidi@inprise.com)


Server Response from: ETNASC04