everal years ago, Bill Watterson wrote a Calvin and Hobbes comic strip where Calvin asked: "How do they know the load limit on bridges, Dad?" and his father answers: "They drive bigger and bigger trucks over the bridge until it breaks. Then they weigh the last truck and rebuild the bridge." That may be humorous when applied to bridge-building, but when applied to programming, it's a little too close to the truth to be funny.
Engineers who build bridges can draw from a wide range of resources that help them design with advance confidence that their products will withstand the required loads. The programming profession needs the same level of confidence. We need to be able to build applications that, when designed according to specifications, will unequivocally withstand their planned loads.
To do that, developers need the equivalent of engineering load-factor tables. Like it or not, programming is leaving the experimental phase and entering a new phase that you may wish to think of as consolidation. Part of that consolidation is to increase the level of standard, transferable, reusable coding practices so that new developers don't have to "drive trucks over the bridge" to discover whether their ideas will work in the real world.
Every profession I can think of has its own jargona unique subset of termsthat function as verbal shorthand, a quick way to transfer a large amount of information as a single concept embodied in a word, a phrase, or an acronym. In fact, frequently, learning the terminology is a fundamental and ongoing step in becoming a member of that profession. Such profession-related terminology isn't, as some feel, only a way to shut out the general public and provide mystery for the acolytes of that profession; instead, it's a natural linguistic progression that lets people communicate efficiently about complex subjects.
|A design pattern isn't "designed," it's discovered. In other words, patterns aren't an invention as much as they are a refactoring of existing concepts.|
In programming, when you realize that you're writing a chunk of code several times, you isolate that code in its own method, class, or module; a process called refactoring. For example, if you have many operations that open and append data to files, you wouldn't normally write all that I/O code inline, you'd create and call methods such as openFile
, and closeFile
instead. Similarly, in spoken and written language, people naturally create shorthand names for complex topics (9/11, Watergate, Iran/Contra, WWII).
Once a group of people all become comfortable with the shorthand reference to a specific type of code or a concept, they can avoid the overhead of describing it "inline" and simply refer to it by that shorthand reference instead. Essentially, the chosen reference acts as a method call or a pointer to the concept or code under discussion, and (just as with actual code) it's far easier to manipulate and more palatable to look at than the concept or code itself.
Programming is rife with such abstractions. High-level languages are themselves nothing more than a set of keywords that abstract lower-level functions. But why stop there? Over the past years, people have recognized that developers could raise the level of abstraction yet again, by grouping common programming constructs into "design patterns," which provide developers with a simple name for these sometimes complex tasks. A design pattern isn't "designed," it's discovered. In other words, patterns aren't an invention as much as they are a refactoring of existing concepts. The "Gang of Four" (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides) captured a core set of such patterns in their famous book Design Patterns.
For example, what's on your programming menu today? Writing an application so that users can run no more than one copy at a time? Write code that watches for newly created files or updates to existing files? Write an application that can be "skinned" or customized by users? Write an application that displays a report in any of several different formats? Theseand many othercommon programming tasks often seem unique at first glance, particularly to less-experienced programmers, but they're not. You don't have to guess or invent a from-scratch solution to these problems anymore; instead, you can take advantage of programming patterns designed to solve such problems, using well-understood and well-tested solutions.