Design Patterns - Deja Vu at Work
Everybody knows what a pattern is. At least, everybody thinks so. Talking about a common-sense term, used in a specific, technical meaning, comes with both malediction and blessing. The upside is that novices don't get scared away as easy as with more "techy" names like "LL(k) grammar." Simple names suggest simple matters. The downside is that this might not be true — as in our case.
|
Patterns are about the same principles we have successfully used in various engineering disciplines for a long time. |
Let's narrow our topic. This article is an introduction to "software design patterns" (subsequently just called "patterns"). Doesn't this sound like an obsolete task, five years after the famous "Gang of Four" book [GoF95] was published? No, there are still many misconceptions around.
Some people think of design patterns as a panacea in the never-ending quest for a rational software design. Some others regard patterns just as another buzzword in the context of object oriented programming. But actually, patterns are about the same principles we have successfully used in various engineering disciplines for a long time:
- solve a certain problem by means of a "good" solution
- abstract both the problem and the solution
- apply this abstract solution to analogous problems.
Don't worry, we won't get lost in philosophical considerations. First, we define the term, then we start to argue about it.
What is a design pattern?
A design pattern is a named set of collaborating classes, used to solve a certain, generic design problem. Too simple? Yes, of course. For those who like to think in terms of pseudo code, here comes a more detailed version:
The values of the emphasized "variables" constitute a certain design pattern. This gives us the following definition:
An (abbreviated) example might look like this:
| Name | Bridge |
| Problem | need to access several alternative class hierarchies without changing client code |
| Intent | separate (visible) abstraction from (hidden) implementation |
| Solution |  |
| Example | Java AWT |
| Analysis | very different ConcreteImplementor classes might lead to fat Implementor interfaces, excessive dynamic casts, or duplicated, differently typed reference fields within the Abstraction hierarchy |
This is just one out of the 23 "standard patterns" described in [GoF95], including names like Abstract Factory, Singleton, State, Composite, Observer and Visitor, to mention just a few of them.
But it doesn't stop with the standard patterns. There are numerous others around, filling whole Web sites, being in a constant process of refinement and consolidation.
You see, there's treasure out there. Let's see how we can dig it up.
How to use design patterns
This actually comes with two questions:- What can we expect from using design patterns?
- Once we are convinced about their value, how do we find the "right" patterns for our problems?
But there is more to it. Using (standard) design patterns significantly eases communication between developers. To carry on with our pattern example, the general design of the Java AWT (Abstract Windowing Toolkit) can be described as:
a Bridge pattern (Components being the Abstraction, Peers being the Implementation), with the ConcreteImplementations being created by a AbstractFactory (the Toolkit class)
One short sentence, that's (almost) all. Compare this to all the diagrams used to depict AWT classes and their relations. Without knowing about the mentioned patterns, we would have to explain at least six classes with 20 methods and fields. That makes a picture which probably takes about 30K to store, compared with the 180 bytes of description above (granted, not a fair comparison, but you get the point).
Page 1 of 2
This article was originally published on November 11, 1999