Smalltalk Best Practice Patterns Volume 1: Coding - Free

Why Patterns WorkHere is the Big Assumption: There are only so many things objects can do. Not in the sense thatthere are a limited number of applications, there will always be new domains to model, but in thesense that the same structures of objects keep appearing over and over, regardless of theapplication. The problems in the construction of objects are universal. You have to name classes,relate classes via inheritance and delegation, relate methods in the same class and different classes,name variables, and so on. Patterns record these problems and how to approach solving them.Communicating with our computers used to be the hardest thing about developing systems. It hastaken years, but advances in programming languages, programming environments, andprogramming style have largely eliminated the barriers to instructing the computer.When the hardest problem is solved, something else becomes the hardest problem. The nextbottleneck in software engineering is human communication. When we say that 70% of thedevelopment budget is spent on maintenance, we mean that the poor maintainers have to wadethrough piles of documentation and code to discover the intent of the original programmer. Theadvent of widespread reuse exacerbates the problem. No longer is one maintainer the audience forone developer, hundreds or thousands or hundreds of thousands of elaborators are trying tounderstand the intent of an abstractor.When you want to improve communication you have two choices, either increase the bandwidth soyou can communicate more bits or increase the context shared between sender and receiver so thesame number of bits mean more. The first is impractical especially in the presence of reuse (onedeveloper can only be sliced into so many pieces), so we must find some way to make our wordsmean more.When you want to optimize any process, the first strategy to employ is to find how the commoncase is simpler than the general case. For software engineering, the general case is theprogramming language. Commonly, though, we don't go all the way back to the programminglanguage to solve problems. We look at what we did last week, and last year, and what our friendsdid last week and last year, and do something similar.Small, tightly knit development organizations demonstrate the cumulative effects of this kind ofoptimization. Because everyone shares the same experiences, a simple word or phrase takes on abig meaning. "I've got this problem, how am I going to solve it?" "Well, you could try thatgraphics editor trick." "Exactly. That should work great." Small organizations becomedramatically more productive when they gather a critical mass of these "catch phrases".There are two problems with relying on an oral tradition to transmit this information. First,members of the team become almost incomprehensible to someone not initiated into the dialect.Second, the process doesn't scale. The team can't grow big without losing the benefits of its privatelanguage, and one team's experience can't transfer easily to another.Patterns are a literary form for capturing and transmitting common practice. Each pattern records arecurring problem, how to construct a solution for the problem, and why the solution is appropriate.By carrying along their justification, patterns avoid the problem of most "style guides" that simplyprescribe solutions without discussing why or when the solution is appropriate. If you are facedwith the recurring problem named in a pattern, after you read the pattern you should be convincedthat the solution called for in the pattern is appropriate or you should know why it isn't.Coding Patterns page 18 of 147 9/30/2006