This post from my original blog and written in 2005, now copied here.
As a Delphi/C#/Java developer, why on earth did I buy and read a SmallTalk book? Am I going out of my mind?
Actually, no. Smalltalk Best Practices is about the day to day tactical things you can do to make your code more readable and more maintainable.
While it clearly has a SmallTalk bias (obvious, given the title), many of the Patterns identified are relevant to any environment, any language
Is it worth reading?
In my mind, any book I read for professional reasons (that is, any book not read for recreation) has to teach me something. This book taught me in two different ways.
Firstly, some of the Patterns presented were novel solutions to some of the issues I’ve run into in the past. In some cases these novel solutions were not appropriate for me, and I haven’t used them. In other cases, learning the pattern has extended my skillset usefully.
Secondly, for some of the patterns I already knew, the explanations were novel or had a new perspective. They therefore have extended my ability to articulate the why behind the choices I make as I code. These explanations have also helped me to better choose between techniques by understanding the pros and cons more fully.
Yes, the book is worth reading.
Who should read this book?
If you are a professional developer who cares about improving your craft, read this book.
For those just starting out as a developers, the advice here will help you improve. You needn’t (and shouldn’t) simply accept everything at face value. Disagreeing, as long as you know why you disagree, is just fine.
Long time developers will find that much of the content falls into the “Well, yeah” category as things that you already do. Even for these people, however, this book has a few gems that make it worth reading.
On the other hand, if you are a language bigot who thinks that Visual Basic ( or Java or C# or Delphi or C++ or Python or Perl or …) is the solution to all the worlds problems, avoid this book. You wouldn’t want your bubble burst.
An Example: Execute Around Method
This is an example of one of the many Patterns identified in the book.
Execute Around Method
How do you represent pairs of actions that have to be taken together?
It is common for two messages to an object to have to be invoked in tandem. When a file is opened, it has to be closed. When a context is pushed, it has to be popped.
The obvious way to represent this is by publishing both methods as part of the external protocol of the object. Clients need to explicitly invoke both, in the right order, and make sure that if the first is called, the second is called as well. This makes learning and using the object more difficult and leads to many defects, such as file descriptor leaks.
Code a method that takes a Block as an argument. Name the method by appending “During: aBlock” to the name of the first method that needs to be invoked. In the body of the Execute Around Method, invoke the first method, evaluate the block. then invoke the second method.
The rest of the discussion has been omitted. If you want to know how it finishes, you’ll need to read the book.
For Non-Smalltalk developers
In Smalltalk, a “Block” is a piece of code much like an anonymous method. Blocks can be stored in variables and passed as parameters.
While C# is reportedly to gain blocks in the next version, you can use this pattern today by passing a delegate.
Delphi developers can also use this pattern, as that language treats Methods as first class values, not as a special case. They can be stored in variables and passed as parameters very easily.
