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 jargon?a unique subset of terms?that 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.
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, appendToFile, 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? These?and many other?common 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.
What’s Your Take?
The problem for software developers lies more in how to disseminate the knowledge and use of design patterns. At DevX, we’ve seen a slow rise in authors’ use of patterns and pattern terminology in the articles we publish, but we would like to know how you feel about them. Are design patterns something you feel are basic building blocks for modern developers? Should developers, when they see a mention of the Observer pattern, for example, instantly snap to the idea behind that pattern, understanding why it would apply to a given situation? Do you relish the idea of invoking a pattern and thus encapsulating large swathes of code and explanation in some articles, letting authors and readers focus on less-common tasks?
And if you feel this way, how far along the process toward a universal understanding of patterns do you think your programming colleagues are? For example, the Model View Controller (MVC) pattern seems to have entered the realm of ubiquity; whereas only the most pattern-passionate devotees will understand more obscure patterns, such as the Bridge Pattern.
Alternatively, do you feel that each situation is unique, and that spouting pattern terminology simply ignores the distinct problems inherent in each programming solution; that design patterns are the embodiment of the “ivory tower” language that permeates abstract programming discussions; and that a pattern devotee’s blithe advice to “use a State Pattern implementation” will only exacerbate the frustration level for someone attempting to get concrete help with a real-world problem?
Also, do you think people really need to learn and understand the pattern terminology when there are an increasing number of less abstract ways to get the same patterns into people’s hands? For example, Microsoft’s Application Blocks encapsulate patterns in generic, reusable, and customizable blocks of code that developers can plug into their applications. Are these simply design patterns by another name or are they the building blocks that developers need?
Yet another approach?probably the one that will eventually bear the most fruit?is to use application generators, where designers focus on high-level descriptions of the objects and tasks required in a system, and computers handle the lower-level decisions. Application generators today rely largely on humans to provide them with the patterns, but it’s likely that future generators will increasingly analyze the tasks to be performed and determine which patterns apply to a given task automatically.
What Do You Want?
At DevX, we’ve noticed an increasing number of references to design patterns in the articles (and applications) that working developers write. And we expect this trend to continue, with more problems solved on the pages of this Web site using, in part, established design patterns. But we want to know what you think:
- Are design patterns important to working developers today?
- How many design patterns are you well versed in?
- Are developers who don’t use design patterns behind the curve? Are they inefficient? Are they control freaks?
- Does solving a problem with a design pattern demand an explanation of the design pattern as well?
- Are you only interested in simple and common patters (such as the Factory pattern, the Singleton Pattern, the Model/View/Controller pattern) or do you want to learn less common patterns (such as the Bridge Pattern, the Façade pattern, the Flyweight Pattern) as well?
You tell us. We’re listening.