Patterns in Practice: Jump Starting Application Development
Mention
patterns to a software developer and it may evoke feelings of both excitement and desperation. Excitement, because patterns promise to unlock the door to faster and more efficient programming, and desperation, because it seems actually making use of patterns can be a real challenge.
In theory, patterns--like blueprints--can provide a useful starting point in the creative process, whether one is building software or living space. Unlike blueprints, however, patterns do not explicitly provide instructions on the processes to follow, instead leaving it up to the developer to determine how a particular pattern can be applied in any given setting.
A bit of background on the subject may be helpful here. The architect, Christopher Alexander, is credited by many for giving rise to the concept of patterns through his pattern language for creating towns and neighborhoods, houses, gardens and rooms. According to Alexander, "Each pattern describes a problem which occurs over and over again in our environment and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice." (Excerpted from,
A Pattern Language: Towns/Buildings/Construction by Christopher Alexander, Oxford University Press, 1977.)
Another, simpler definition of a pattern is a "reusable idea or concept," and it is this definition that serves as the basis for our discussions. From a programmer's standpoint, perhaps the most notable reference on the subject of software patterns is Design Patterns: Elements of Reusable Object-Oriented Software, (Addison-Wesley Publishing Co., 1995) written by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (known collectively as the "Gang of Four" or GoF). While presented in abstract form, this book offers a catalog of design patterns from which to choose-from creational patterns to structural patterns to behavioral patterns.
Since its publication in 1995, others have worked to make these patterns more useful to programmers, by writing code to accompany the patterns and offering examples of how organizations can successfully implement them. One such work,
A Learning Guide to Design Patterns, by Joshua Kerievsky (Industrial Logic, Inc., 1998) attempts to guide users through the maze of patterns presented in the GoF's design book and looks at effective strategies for deploying them. Another book,
Analysis Patterns: Reusable Object Models (Addison-Wesley Publishing Co., 1996), written by industry consultant, Martin Fowler, explores the use of patterns as a means of capturing and reusing ideas that reflect conceptual models of business processes, and offers a collection of patterns that apply across various business domains.
But beyond the books, of which there are a growing number, the key to understanding and using patterns seems to come down to just one thing -practice. "Patterns aren't a panacea," says Fowler, who along with software development guru, Grady Booch, kindly agreed to participate in an informal Q&A on the topic of patterns for this article.
On Patterns: Straight Talk on What Makes Patterns Really WorkAn interview with Grady Booch, chief scientist, Rational Software (Cupertino, Calif.) and Martin Fowler, independent consultant and author of Analysis Patterns: Reusable Object Models (Addison-Wesley Publishing Co., 1996) and Refactoring: Improving the Design of Existing Code (Addison-Wesley Publishing Co., 1999).
MRS: There's been a lot of talk about patterns making their way into software development over the past few years. Are we really seeing patterns being put into practice today?
GB: Absolutely. Virtually every software development organization I encounter is using the language of patterns to help them organize the architecture of their software. For example, Boeing's work on the modernization of the AWACS software uses patterns. I've also been working with a number companies engaged in building systems for e-business companies, and every one of them uses patterns, some straight out of the classic Gang of Four (GoF) work, and others of their own making. Even the design of Sun's Jini has been shaped by patterns.
MF: Oh, we've seen patterns showing up in applications for many, many years--that's not news at all. Any developer who sits down and reviews a piece of software and then says, "Oh, I can make use of that!" and then writes some code--who effectively is inspired by, or follows that pattern-is using that pattern. People have been doing that for a long time. It's certainly growing, you're seeing more people doing this, but even before the GoF's book,
Design Patterns: Elements of Reusable Object-Oriented Software, (Addison-Wesley Publishing Co., 1995) people were using patterns. Really, patterns are being applied whenever somebody recognizes a pattern then uses it to help guide them in writing the software that they're working on.
MRS: Some programmers argue that patterns are useful when building a new application, but for existing or legacy applications, it's often difficult to determine how to apply this type of methodology - i.e. "The pattern just doesn't fit." What is your response to this observation? Do you agree or disagree? Why?
GB: Old software tends to get brittle over time and change, so indeed, lots of things are more complicated when dealing with legacy software. You're constrained by past decisions and technology, and as you modify an older system, you often don't have a clear picture of the architecture and details that went into its creation. That being said, patterns are a very useful concept to apply when you're working on legacy code, because they give you the opportunity to refactor its structure, thus actually improving and refining its architecture while you're making changes. For example, suppose you're making an older system Web-ready (a very common activity these days). One element of making that happen is to devise a common mechanism that delivers data from the legacy system to a browser, but give the illusion to the legacy system that this looks just like a terminal interface. That's a pattern: a common solution to a common problem.
MF: Patterns certainly are valuable when you begin coding, but they're equally valuable as you're making changes to existing code. In fact, in many ways, patterns are even more important to use with existing code, because that's when you often discover that you need some additional flexibility in your current system. If you don't know how to refactor, you may find it difficult to add patterns to existing code, because you're changing the code base and you don't know how to do it effectively. That's why people need to be taught about such techniques as refactoring.
Refactoring is all about how to make these transformations to improve the quality of code. The problem is that as an industry we haven't placed much importance on how to transform existing code and keep it in a good condition. We've kind of resigned ourselves to believe that, "Oh, well-we'll come up with a design but it will gradually deteriorate and fall apart over time," and I think that's a misuse of software. The whole point of software is that it should be adaptable in the long term, and you should be able to make changes to it. Yet very few people have focused on how you can make changes to software in an efficient and controlled way-refactoring is the first technique that I've come across that really looks at that, which is why I got so excited and decided to write a book about it. I think we need to look at more techniques like refactoring in order to build truly evolve-able software.
MRS: Based on your experience, what does it take to successfully implement patterns? (How important is formal training, for example? What kind of learning curve is involved, typically?)
GB: The key to successfully using patterns, I think, is the ability to abstract. Teams that understand the object-oriented principles of abstraction, encapsulation, distribution of responsibilities and separation of concerns tend to grasp patterns more readily than those teams that do not. In most of the teams I've encountered, they picked up patterns just by following the literature that's in the market and on the Web. (For relevant resources, see
Pattern Matching? sidebar below.) As for the learning curve, I've found that patterns are something that easily enter the vocabulary and practice of your system's architects.
MF: The key starting point is to gain familiarity with patterns and to spend some time reading. A lot of it's a matter of going back and forth-looking to see if any of the patterns you come across seem as if they might be applicable. I often encourage programmers to try a pattern out and if it doesn't turn out to be helpful, then they've still learned a lot--both about their problem and about the pattern. So, in my view, it requires a lot of reading and experimentation.
In terms of training, patterns training is particularly difficult to do well. The problem is that a lot of training is based upon passing on rote knowledge concepts and is often conducted by people that may not have a great deal of practical experience. One person who has spearheaded a different kind of training effort in the area of patterns is Joshua Kerievsky. Joshua set up a user group several years ago and the style of training he initiated was very interactive. The group would meet once a week, and using the GoF's Design Patterns book, they would hold in-depth discussions on one pattern during each session over the course of a few months. They had a lot of success with that in New York. Joshua now lives in San Francisco and the group is still going strong.
MRS: In what scenarios are patterns most useful? (Can a pattern be applied for an entire domain, for example, or are patterns most useful for lower level activities?)
GB: Patterns form a spectrum. Closest to code, there are idioms, which represent common solutions to common programming problems. Jim Coplien and others have documented a number of such C++ idioms, for example. Moving up the food chain, there are design patterns, also known as mechanisms, and these are best typified by the GoF's book, Design Patterns. These mechanisms are beginning to impact the overall architecture of the system. Even larger are architectural patterns, which essentially are micro-architectures for vertical systems. IBM's San Francisco frameworks are patterns, as is their Insurance Application Architecture. In that light, you'll find horizontal patterns (such as the GoF's design patterns) as well as vertical ones (such as San Francisco).
MF: I find patterns useful all over the place. Many of the patterns are individually very small pieces, but they're everywhere. If you look at a well-designed object-oriented system, you'll typically see many of the GoF's design patterns all over the system--many patterns appear again and again and again. That's the quality that makes a pattern a pattern--it can be used again and again and again. Patterns really can apply at pretty much any level where you've got a repeating experience.
MRS: What are the overall benefits of applying patterns in application development? The limitations?
GB: Patterns help you a) simplify your system's architecture, b) increase the bandwidth of communication within your team, and c) generally help raise the level of abstraction in your development process. As for limitations, the challenges are in how best to describe and communicate a pattern. We're using the UML (Unified Modeling Language) quite successfully to capture the syntax and semantics of patterns.
MF: Well, patterns accelerate your experience--when you're starting out doing a new kind of system and you haven't got much experience in that field--if you're able to find a good set of patterns that describes some of the techniques for you, it gives you a big boost, because you're building on the knowledge of other people and that's really what it comes down to-it passes on experience. That's the advantage--so, whether you're working on a existing system or developing a new system, you're able to see how to move because you've got some of this experience to work with. You can compare what you're doing to these patterns and ask ,"Am I doing this the best way?" Patterns involve more than just a solution-they also talk about the tradeoffs that make the pattern worthwhile or not. And that's one of the most important parts of patterns--this discussion of tradeoffs. One of the things that I do in my consulting work is to compare what somebody's doing to a pattern that I've already come across, and that allows me to determine whether the pattern is appropriate, or if some other approach should be used. Patterns allow us to think more about the tradeoffs, that's all.
Fundamentally, patterns are limited because of what they are--a teaching tool. They're simply a way of capturing design experience. While patterns can help you develop software, you're still dealing with a fundamentally complex task. That's just the nature of software development. To me, patterns are a vehicle to help in the continuous study that you have to do to become a good designer. Patterns can accelerate the learning process, but they don't magically wave it away.
MRS: What role do you envision patterns will play in software development over the next decade?
GB: Patterns are already part of the mainstream of software development. I think what you'll see over time is the codification of more and more common solutions to common problems in the language of patterns. The low hanging fruit right now is the codification of architectural patterns for Web-centric systems. There really are only a few meaningful architectures for such systems, most of which have been discovered by trial and error. There are now opportunities to codify those patterns, making that experience accessible to a wider community now struggling with building e-business solutions.
MF: What I certainly hope is that more people will put time into capturing and describing patterns and passing them on and they'll all build up to be a body of best practices. One of my holy grails is to be able to have something akin to engineering handbooks--books that say if the load is so and so here, here's the formula to calculate the stresses on a particular system--these things have been figured out. That's the way I hope it will one day be in software. That you would say, "Oh, I need to implement some accounts payable functionality--and, here's a book on the patterns to use for this and it will tell me when to use these patterns and when not to, and which patterns to put together, etc."
Of course, the patterns won't write my code for me, but they'll give me a lot of guidance and allow me to do my work more quickly and to produce better quality work in the end. The library I'm envisioning would require quite a large bookshelf--offering a well-organized collection of these patterns, much in the same way that engineering handbooks have grown over the years. Obviously, we're a long way away from that--we've got a handful of books, and presently, they're not particularly well-organized-but that's where I hope it will go. And I think it will probably take 50 years before we get there. After all, what we're really trying to do is to capture and record the experience of a whole profession-and that kind of thing takes time.
Want more on pattern matching? Try these resources.
Try enteract.com for concepts and terminology or hillside.net, the patterns homepages
A Learning Guide to Design Patterns - Joshua Kerievsky (Industrial Logic, Inc., 1998)
A Pattern Language: Towns/Buildings/Construction - Christopher Alexander (Oxford University Press, 1977)
Analysis Patterns: Reusable Object Models - Martin Fowler (Addison-Wesley Publishing Co., 1996)
Design Patterns: Elements of Reusable Object-Oriented Software - Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (Addison-Wesley Publishing Co., 1995)
Pattern Languages of Program Design - edited by James O. Coplien and Douglas C. Schmidt (Addison-Wesley Publishing Co., 1995)
Pattern Languages of Program Design 2 - edited by John M. Vlissides, James O. Coplien and Norman L. Kerth (Addison-Wesley Publishing Co., 1996)
Pattern Languages of Program Design 3 - edited by Robert C. Martin, Dirk Riehle, and Frank Buschmann (Addison-Wesley Publishing Co., 1997)
Refactoring: Improving the Design of Existing Code - Martin Fowler (Addison-Wesley Publishing Co., 1999)
The Patterns Handbook: Techniques, Strategies, and Applications - compiled by Linda Rising (SIGS Books/Cambridge Press, 1998) |