Smalltalk Best Practice Patterns Volume 1: Coding - Free

What’s Missing?There are a few coding topics I don’t cover here, not because they aren’t important, but because Idon’t understand them well enough yet to turn them into patterns. I hope I learn enough about themto include them in a second edition. Here are the topics I know about:Exception handling. I use exception handling as sparingly as possible, generally only aroundthe highest level invocation of objects from the user interface. Lots of handlers makedebugging difficult, because the code just runs to completion but provides the wrong answer.When you use exception handling, you have to think like the writer of a new programminglanguage, not just an application developer.Copying. Fixing bugs by making copies of objects before operating on them is nice and simple.Unfortunately, when copying becomes a habit, you can end up slowing down your system bymaking unnecessary copies, or introduce bugs by not changing objects that need to be changed.Become. There are legitimate uses of become, but debugging code that uses it is difficultenough that if you have any other option for solving your problem, you’re probably better off.If you are experienced enough to be an exception to this rule, then you won’t be taking what Iwrite as gospel anyway, so I’m not afraid to be doctrinaire on this point.Performance. Performance tuning is a whole topic unto itself. Its biggest problem in thiscontext is that all the patterns here maximize the communication value of code. Performancetuning often sacrifices clarity for speed.The definition of “coding” in the first section of this chapter, namely tactical programmingdecisions, excludes many topics. Here are some of the topics I hope to cover in future volumes:Design. There are a host of techniques that are just upstream (to my view) of the materialcovered here. They are the patterns whereby two objects can do a better job than one, or whenturning a method or set of methods into object provides leverage. For now, I will refer you to“Design Patterns” by Gamma et. al.Modeling. The patterns here resolve constraints imposed by Smalltalk. Many of the mostimportant decisions you make must also resolve constraints imposed by the problem you aremodeling.Requirements. How you agree with the client about what must be done, and more importantlywhat need not be done, has an enormous impact on the success of your development. If youdon’t do what’s needed, the client will not be satisfied with the result. If you do what isn’tneeded, you add cost, time, and most importantly risk to your project.User interface design and implementation. Designing interfaces that users find valuable is anart. Implementing them simply, flexibly, and reusably is the test of solid Smalltalker.Coding Patterns page 14 of 147 9/30/2006