Category Book: Smalltalk Best Practice Patterns by Kent Beck, Prentice Hall, 1997, ISBN:0-13-476904-X. (save $6.00 at bookpool www.bookpool.com 
)
I got tired of going to clients and seeing them make the same stupid mistakes over and over again. Isn't this what patterns are supposed to address?
I started writing patterns in my Smalltalk Report column that tried to tell people what I did that kept me out of trouble. To my mind, most programming is not about going up on the mountaintop, being struck by lightning, and bringing down "the answer" carved on stone tablets. Most programming is applying yesterday's solutions to today's problems. Most of the time a client is convinced I am a genius, I've just applied a pattern that they don't know. I'm not a great programmer, I'm a pretty good programmer with great habits.
Hence, the Best Practice Patterns. I will be publishing them in book form[1] over the next few years. I expect to divide the patterns up into digestible chunks that address a coherent need, like user interface design and implementation or project management.
-- Kent Beck
This is a really cool book. I consider myself an intermediate-level Smalltalk programmer, and reading this book was one of the major forces that boosted me out of apprenticeship. I particularly like the chapter on the Collections classes: it's the first explanation I've seen that concentrates on "why" rather than "what". For instance, the writeup on Array explains how to decide whether an Array or an Ordered Collection is the most appropriate fit. The entire chapter organizes the Collections and their methods into a coherent world-view; after reading it, I feel I have a much better understanding of which tool to use for which task.
I've found it kind of fun to open this book every once in a while in the bookstore to see if I can figure out a bit of Smalltalk from it. I know that it isn't the best way the pick up a language on a ten minute a week budget, but the brief examples and very direct writing style have helped me get a feel for the language (in what little time I have) that I don't get from opening one of the big tomes. I'll probably buy it when I am committed to actually learning the language. -- Michael Feathers
Buy it anyway. I reckon about 50% of it is completely Smalltalk-specific but the other 50% is just good programming practice whatever the language. Intention Revealing Selector is one that should be given to every new developer that joins Microsoft.
Michael, I did sort of the opposite. I fooled around with Dolphin Smalltalk a tiny bit several months back, but not enough to learn it. In the meantime, I had been looking at Kent's book here and there in bookstores. I finally picked it up a month ago. I had read enough bits of it to know it wouldn't be wasted on a Java programmer. But it also inspired me to learn more Smalltalk! --Kiel Hodges
You obviously have good taste in books, Sam :-), and dang! you're going to be good in a few weeks. My head hurts from just thinking about cramming $500 worth of books into it. --Alistair Cockburn
Just to second some of the above - read this whatever language you program in. --David Harvey
Just don't read it to find Squeak-style programs to type in ;-) --PCP
BTW, anyone have any idea why the defacto standard changed from having an abstract class named IndexedCollection to the later trend of having an abstract SequenceableCollection? I know it's not important, but I was just curious about what caused this change in most library implementations? --rad
Since arrays and linked lists are the two, competing, primal data structures in Computer Science...? --Phl Ip
I agree that a lot of this book is applicable to other languages. I bought it after reading so many recommendations. To me style and idioms might be more accurate than patterns. I've found it particularly applicable to the Suneido Language, which is very similar to Smalltalk in philosophy, if not implementation. --Andrew Mc Kinlay
I cannot thank enough Kent Beck and this book. This book has changed my way of programming and has changed my thoughts on programming fundamentally. I almost read this book in tears. I think this book is not to read but to live -- you should rechew the book and confirm it in the context of your daily life, uh programming life as well. This book can look very simple and common sense, but that's the power of this book. Apply the practices daily, and you'll see the simplicity accomplishes the complexity. --June Kim
In Smalltalk Best Practice Patterns Kent Beck writes:
A simple criteria I use all the time is checking rates of change. I learned this criteria from something Brad Cox said a long time ago. I've since generalized it to -- don't put two rates of change together. Don't have part of a method that changes in every subclass with parts that don't change. Don't have some instance variables whose values change every second in the same object with instance variables whose values change once in a month. Don't have a collection where some elements are added and removed every second and some elements are added and removed once a month. Don't have code in an object that has to change for every piece of hardware, and code that has to change for every operating system. How do you avoid this problem? You got it, lots of little pieces.
Can anyone elucidate this criterion? Give examples for its use?
I can confirm that this applies to codelines in parallel development efforts. In parallel development, there may be more than one "active" line of code changes going on. The most common case is when one codeline is being used for maintenance-only and the other is used for new development.
In this situation, and in many others regarding parallel (not concurrent, but parallel) development, one of the motivating factors to branch of a new codeline is because the two efforts have incompatible Rates Of Change: The group on the development codeline may be working on significant changes/additions to functionality; while the maintenance line is used for bugfixes with a quick turnaround time. The frequency of integration (or relative volatility/stability of the codeline after each integration) often needs to be different, and the more frequent integrations unduly disrupt the folks doing the new development (even though they may not even be touching the same pieces of code).
With separate codelines each group can integrate and create new baselines at their own needed frequency, and the one can integrate with changes from the other at their own pace. (PLEASE let us not start a "Continuous Integration is better" war on this page; This is a different context from XP and each practice fits very well within its own context ;-)
So it is an exceedingly common Parallel Development "best practice" to use separate, parallel codelines for pieces of development effort that have incompatible Rates Of Change. --Brad Appleton
This observer believes that Beck is not addressing parallel codelines in the quote above. Beck is referring to the code, saying for example that all the instance variables in an object should change at roughly the same rate. Brad is talking about the coding, i.e. parallel codelines for development efforts with different Rates Of Change. Brad answers whether parallel codelines are good with "yes", dubbing it a "best practice".
See original on c2.com