Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Webster’s Dictionary defines a pattern as both “a form or model proposed for imitation” and “something designed or used as a model for making things.” In the world of physical things we can see and touch, pattern use is easy to comprehend. An auto manufacturer uses many patterns for the different models they produce. Or, a pattern might go by a more specialized name, such as a blueprint in construction.
What all patterns have in common is a level of abstraction and a solution to a problem. The level of abstraction means that a pattern for a car is not the actual car itself but some representation of what a car is. Patterns can have varying levels of abstraction. For instance, the broadest car abstraction might be four wheels, an engine, a steering wheel, a place for the driver to sit, a drive mechanism, and frame. From there, we get less abstract and more specific if we define categories such as race car, passenger car, sedan, convertible, sport utility vehicle, front-wheel drive, and so on, adding the necessary details for each one. From there, each car maker will fine tune the components of each.
The pattern also offers a solution. Sticking with the car example, the pattern provides the solution to questions like “where is the best engine placement for handling on slick roads” or “what steering system provides the best driver control in a sports car.”
Patterns in software exist for the same two fundamental reasons. First, they abstract similar applications into a pattern that can be applied over and over again. Second, they provide solutions to problems in a business (“how do we integrate our customer service database with our order tracking”) or software development (“what’s the fastest full-text search algorithm”) sense.
Software patterns come in varying levels of abstraction. Some are written in pseudo-code for very broad problems. Others are written for a specific language (Visual Basic, C#, Java, or others) and solve a very specific need. Patterns are now recognized as a fundamental concept of reusable coding practices in object-oriented programming, although this concept wasn’t formally introduced to programming until relative recently, when in 1995 Eric Gamma and his co-authors introduced them in the text Design Patterns. In this book, they defined four core elements of a pattern: the name, the problem the pattern applies to, the solution, and the consequences. (This book and the co-authors are sometimes referred to as the “Gang of Four” or GOF.)
Pattern problems need to include some context, explaining the types of situation the pattern is useful for and the boundaries for that situation. Patterns should have been used, tested, and proven to work before they are called patterns. Otherwise, they are hypothetical and the results would be unknown.
To go from a pattern to an implementation still requires significant human involvement. A pattern isn’t a ready-made or plug-and-play solution. Nor is it a class that can simply be reused in and referenced. To go from the pattern to a working system, the developer has to examine the systems the solution will interact with, the details of the business need to be addressed, and write the actual application code.
Patterns are a formalization of something that good software designers do all the time—reusing parts of a previous solution in a new application. When a good software designer sees a problem that looks similar to something they’ve already solved, they won’t start coding from scratch, but they’ll begin the same design they tried and tested before, modifying it to suit the new needs. Using this approach, and using formal patterns, saves time designing something new and saves time testing. The bottom line on patterns could be summed up by the phrase “Don’t re-invent the wheel.”
However, the availability of patterns won’t make an inexperienced programmer great. You still need to understand the pattern’s limitations and tradeoffs. An experienced programmer can easily misuse a pattern along the lines of the saying “If you have a hammer, everything looks like a nail.”
For further reference, see:
- Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
- “What are Design Patterns and Do I Need Them?“
About the Author
Jim Minatel is a freelance writer for Developer.com in addition to working with Wiley and WROX publishing. He maintains a blog at http://wroxblog.typepad.com.
