Beck - Smalltalk Best Practice Patterns

Kent Beck

Library of Congress Cataloging-in-Publication Data

Beck, Kent.
Smalltalk best practice patterns / Kent Beck.
p. cm.
Includes index.
ISBN 0-13-476904-X (pbk.)
1. Smalltalk (Computer program language) I. Title.
QA76.73.S59B43 1997
005.133--dc20 96-29411
CIP

Editorial/Production Supervision: Joe Czerwinski
Acquisitions Editor: Paul Becker
Manufacturing Manager: Alexis R. Heydt
Cover Design Director: Jerry Votta
Cover Design: Design Source

1997 by Prentice Hall PTR
Prentice-Hall, Inc.
A Division of Simon and Schuster
Upper Saddle River, NJ 07458

The publisher offers discounts on this book when ordered in bulk quantities. For more information, contact:

Corporate Sales Department
Prentice Hall PTR
One Lake Street
Upper Saddle River, NJ 07458
Phone: 800-382-3419
Fax: 201-236-7141
E-mail: corpsales@prenhall.com

All rights reserved. No part of this book may be reproduced in any form or by any means, without permission in writing from the publisher.

Printed in the United States of America

10 9 8 7 6 5 4 3 2 1

ISBN: 0-13-476904-X

Prentice-Hall International (UK) Limited, London
Prentice-Hall of Australia Pty. Limited, Sydney
Prentice-Hall of Canada Inc., Toronto
Prentice-Hall Hispanoamericana, S.A., Mexico
Prentice-Hall of India Pte. Ltd., New Delhi
Prentice-Hall of Japan, Inc., Tokyo
Simon & Schuster Asia Pte. Ltd., Singapore
Editora Prentice-Hall do Brasil, Ltda., Rio de Janeiro

This preface will explain what this book is about. It will convince you to buy this book, or you will know why you shouldnt (more of the former than the latter, I hope).

This book is about the simple things experienced, successful Smalltalkers do that beginners dont. 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 dont 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 doesnt make formatting difficult.

You dont want redundant information 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 doesnt 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 dont 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 tomorrows problems.

LearningIf you are just learning Smalltalk, these patterns will give you a big jump start on making effective use of the system. Because the patterns arent 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.

ProgrammingIf 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 or present nuances you hadnt considered.

TeachingIf 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.

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

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 want to learn to write patterns yourself, or understand their philosophical or psychological basis, you wont 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 arent the topic of this book. This book is about making Smalltalk work for you. Making objects work for you is an entirely different topic.

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 didnt 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.