PREFACE:

This preface will explain what this book is about.

It will convince you to buy this book, or you will know why you shouldn't (more of the former than the latter, I hope).

What's it all about?

This book is about the simple things experienced, successful Smalltalkers do that beginners don't. In a sense, it is a style guide. I have tried to penetrate beneath the surface, though, to get at the human realities that make the rules work instead of focusing solely on the rules themselves.

The topics covered are the daily tactics of programming:

How do you choose names for objects, variables, and methods?
How do you break logic into methods?
How do you communicate most clearly through your code?

These are small scale issues. There are also many bigger technical reasons why projects fail (and many more nontechnical reasons).

The attraction of this set of issues is that they are so tractable. You don't have to be a programming wizard to pick good names, you just have to have good advice.

The advice is broken into 92 patterns. Each pattern presents:
a recurring daily programming problem;
the tradeoffs that affect solutions to the problem; and
a concrete recipe to create a solution for the problem.

For example, here is a summary of a pattern called Role Suggesting Temporary Variable Name:
Problem: What do you name a temporary variable?
Tradeoffs:
You want to include lots of information in the name.
You want the name to be short so it is easy to type and doesn't make formatting difficult.
You don't wantredundantinformation in the name.
You want to communicate why the variable exists. You want to communicate the type of the variable (i.e. what messages it is sent). Solution: Name the variable after the role it plays. The type can be inferred from context, and so doesn't need to be part of the name. You will see in the body of the book that each pattern occupies a page or two. Each pattern includes examples (and counter-examples) from the standard Smalltalk images.

Each pattern also talks about related patterns. The patterns don't stand in isolation, 92 independent bits of advice. Patterns work together, leading you from larger problems to smaller. Together they form a system or language. The system, as a whole, allows you to focus on the problem at hand, confident that tomorrow you can deal with tomorrow's problems.

Why should you read it?

Learning—If you are just learning Smalltalk, these patterns will give you a big jump start on making effective use of the system. Because the patterns aren't just rules, you can smoothly go from merely following the patterns, to understanding why they are the way they are, to formulating your own patterns. You will need a good basic introduction to Smalltalk in addition to this book, but reading them together will greatly accelerate your learning.

Programming

If you program in Smalltalk, these patterns will give you a catalog of techniques that work well. You will have discovered or invented many of them yourself, but the patterns may give you a fresh perspective on why they work present nuances you hadn't considered.

Teaching

If you teach Smalltalkers, either as a mentor or in classroom training, these patterns will give you large bag of instructional material. If you are trying to explain why code should be different, it is much more satisfying for you and the learner to be able to discuss the pattern and how it applies to the particular situation.

Managing

If you manage Smalltalk projects, you may be struggling with how to apply good software engineering principles to Smalltalk. These patterns don't address that topic directly, but they can become the basis of a common vocabulary for your developers.

What isn't it about?

This is not a book of methodology. It will not guide your entire development process. You can use it with your existing process, whether you invented it or it came out of a book.

This book is about making code that works for you. This is not a book of philosophy. If you want to understand what makes programs good in the abstract, if you went to learn to write patterns yourself, or understand their philosophical or psychological basis, you won't find any help here. This book is for people who have programs to write and want to do so as quickly, safely, and effectively as possible. This is not a book of design. If design is the process of defining the relationships among small families of objects, the resulting problems repeat just as surely as do implementation problems. Design patterns are very effective at capturing that commonality. They just aren't the topic of this book.

This book is about making Smalltalk work for you.

Making objects work for you is an entirely different topic.

Acknowledgments

I would like to thank the many people who contributed to this volume. First I would like to thank the Xerox PARC Learning Research Group (Alan Kay, Adele Goldberg, Dan Ingalls, Diana Merry-Shapiro, Ted Kaehler, Larry Tesler, and Bob Flegel) for having the insights in the first place, so I had something to write down.

I would like to thank my mentor and intellectual partner, Ward Cunningham, for showing me the way and sharing his insights. Many of the patterns here he identified and/or named. Thanks to my reviewers (Dirk Riehle, David N. Smith, Mitchell Model, Bill Reynolds, Dave Smith, Trygve Reenskaug, Ralph Johnson, John Brant, Don Roberts, Brian Foote, Brian Marick, Joe Yoder, Ian Chai, Mark Kendrat, Eric Scouten, Charles Herring, Haidong Ye, Kevin Powell, Rob Brown, Kyle Brown, Bobby Woolf, Harald Mueller, Steve Hayes, Bob Biros, David Warren, Gert Florijn, Mark L. Fussell, Martin Fowler, Chuck Siska, Chris Bird, Ron Jefferies, Volker Wurst, Peter Epstein, Thomas Murphy, Michel Brassard, Ron Jefferies, John Sellers, Steve Messick, Darrow Kirkpatrick, Phoenix Tong, Doug Lea, Randy Stafford, Sharry Fealk and all the reviewers who didn't put their names on their comments) for reading early rough drafts carefully. Finally, this book would never have been finished without my ever patient but gently prodding editor, Paul Becker.