The concept of patterns keeps coming up in the world of application architecture, and rightfully so. In a world where reuse is more lip service than reality, and where sound object modeling yields to RAD-in-a-minute, we need a better way to capture reusable elements both intra- and interproject. Patterns provide the conceptual infrastructure to find and refine the commonality that's always there with applications.
Patterns, however, are not accessible to the general application architect and developer population. Not that application architects or developers can't use patterns, but they don't know where patterns fit into object-oriented client/server development. Also, patterns are just too abstract to be practical. The fact is, until recently, patterns were more a topic for academic debate and deep object-oriented conference papers than a sound application architecture concept. Moreover, patterns are nothing new. I've been reading about patterns for over a decade now.
Patterns began with the work of an architect named Christopher Alexander during the late 1970s. He published two books, A Pattern Language (Oxford University Press, 1977) and A Timeless Way of Building (Oxford University Press, 1987). Not a lot was heard about patterns until we became interested in object-oriented development in the late 1980s when many papers and presentations appeared, authored by people such as Grady Booch, Richard Helm, Erich Gamma, and Kent Beck. In 1995, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides published Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Publishing Co., 1994). However, the best book on patterns for application architects is Pattern-Oriented Software Architecture (John Wiley & Sons, 1996) by Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal. (It served as a reference for me for this column, by the way.)
Today, we've refined the concept of patterns so that they are usable by non-Ph.D. types, and I believe they add a great deal of value to the development process (that is, as long as you can see the value beyond the seemingly complex concepts). Let's take an overview of patterns and find out where they fit into modern application architecture and why I think they should be part of your personal knowledge base.
Even if you don't know what patterns are, you probably used the concept in your last software development project without even realizing it. Simply put, patterns allow you to spot common features (such as problems and solutions in systems), capture that information, and reuse it over and over again from project to project, application to application. It's the common theme of object-oriented development: Build it once, reuse it everywhere. Patterns allow us to formalize and streamline this process.
In the context of application architecture, patterns describe certain recurring problems that appear in certain design contexts. Patterns describe generic schemes for the solutions to the problems. The solution scheme is created by defining its components, responsibilities, and relationships. There is a three-part schema that's a part of every pattern: context, problem, and solution. Context means the situation giving rise to a problem, while the problem is the recurring issue arising from the context. The solution is the well-proven and consistent resolution of the problem.
The following problem by Christopher Alexander is a classic textbook example of patterns. (Excerpted from A Pattern Language by Christopher Alexander, Oxford University Press, 1977.)
IF you find yourself in CONTEXT
for example EXAMPLES,
with PROBLEM,
entailing FORCES,
THEN for some REASONS,
apply DESIGN FORM AND/OR RULE
to construct SOLUTION
leading to NEW CONTEXT and OTHER PATTERNS.
The context describes the circumstances of the situation where the problem arises, or what has to be true for the pattern to be valid. For example, an object uses data from an external system.
The problem is what's addressed by the pattern, and this problem arises over and over again in the context. The idea is to capture the essence of the problem or what design issues define the problem. For example, changing the state of the object means that the object and the external data are inconsistent. Thus, you need to synchronize the external data and the object.
The solution, of course, is the part of the pattern that solves the problem. There are two issues here. First, every pattern should specify a specific structure. Second, every pattern needs to define run-time behavior. The idea here is to provide a "cookbook" to allow you, and others, to solve the problem defined in the pattern. For example, using a synchronization mechanism to migrate data automatically to and from the external database to the object would be a solution to the problem I just defined.
If this is all beginning to come together now, you're seeing how patterns are nothing more than a formal methodology for analyzing and making sense of problem domains, with the outcome being reusable work. For instance, if you've built a lot of systems you know that accounting systems and inventory systems are very different in purpose, but very similar in the types of design and architectural problems you're trying to solve. Therein lies the value.
All patterns are not created equal. There are types or categories of patterns you want to use in specific situations. For instance, some patterns help application architects structure a system into subsystems, while other patterns let you refine the subsystems and how they interact. Some patterns help application architects determine design aspects using pseudo-code or a true programming language such as C++. Other patterns address domain-independent subsystems or components, or domain-dependent issues such as business logic.
Although it's difficult to categorize patterns, it's generally accepted that architectural patterns, design patterns, and idioms exist. Architectural patterns provide application architects with a basic system structure, such as subsystems, behavior, and relationships. In a sense, architectural patterns are templates for application architecture, defining macro system structure properties. Architectural patterns are complex in nature and tend to link to particular domains such as transaction-processing systems.
Design patterns provide application architects with a means of refining the subsystem of components, as well as the relationships among them. The idea here is to find a common structure that solves a particular problem. Design patterns are not as complex as architecture patterns and tend to be problem-domain independent. For example, capturing a set of interface patterns that maps to many system types. An idiom is a low-level pattern coupled with a specific programming language such as C++ or Pascal. Thus, an idiom describes how to code the object at a low level.
Pattern descriptions should provide specifications for deploying the pattern. These are called micromethods, and they provide application architects with such problem-independent analysis and design methods as you would find in traditional object-oriented analysis and design methodologies such as Booch, the Object Modeling Technique (OMT), and the Unified Modeling Language (UML). Patterns provide object-oriented analysts with a methodology for solving recurring problems.
Not sold yet? Well, there are many benefits in using patterns for application architecture, such as the ability to solve recurring design problems that typically arise in application architecture and construction. The data migration example I gave earlier, for instance, creates a reusable solution set that application architects can apply to multiple applications. We already do this to a certain degree, but we have a tendency to keep the information in our heads, where it's either forgotten or you're just not around to share the information with those who need it when the problem arises once again. What's more, application architects--even the good ones--are poor documentation generators; I'm certainly as guilty of this as anyone.
Patterns do a good job of recording design experience across a development group. Typically, such knowledge is found in the minds of the experts that may be on the team. Patterns level the playing field, providing every team member with the means of using this valuable information. Application architects may create a database of architecture patterns with search features and even links to code and models.
Patterns also provide a standard vocabulary and base set of concepts for application architecture. Thus, you should pick the words you use to represent concepts carefully to make sure that everyone understands what you're talking about. This saves time because you no longer need to keep describing concepts to other team members. Following this concept, patterns provide a natural mechanism for documenting application architectures.
Patterns allow application architects to create complex architectures because patterns provide predefined components, relationships, and responsibilities. Patterns are able to serve as components or artifacts for building more complex architectures. The idea is to build systems using these predefined and proven solutions. However, I've found that, in many cases, patterns don't provide all of the design detail you'll need to solve the problem at hand, but they do provide a nice starting point. Remember that patterns provide generic solutions. Moreover, patterns provide application architects with the skeleton of functionality.
Patterns allow application architects to manage software complexity because all patterns provide predefined methods to solve a problem. For example, when you run into a problem in designing a system, you don't need to reinvent the wheel. Instead, you simply find the pattern that describes the problems and implement the solution. That is, assuming that the pattern is sound, you should only capture sound patterns with solutions that work.
The bottom line with patterns is that they add value to the application architecture and the software development lifecycle. They are also great time savers and have the potential to increase the quality of most system development without increasing cost. You need to keep a few things in mind, however.
First, you should not jump into patterns as a mechanism to replace a sound methodology and a sound process. Instead, patterns are able to become part of each, and in many instances there is already some pattern-oriented software architecture in place. Patterns simply formalize the process, filling in the gaps and providing a consistent approach. I've heard some compelling talks describing patterns as the Second Coming of software architecture. However, I've seen no evidence to validate those assertions. Patterns are simply another tool at our disposal.
Second, patterns only add value if they are practiced consistently over time. Just capturing patterns for one application is hardly worth the trouble. Application architects must establish the infrastructure for patterns, creating standard mechanisms to capture and maintain the patterns over the long haul, refining patterns when necessary. For instance, the vocabulary should be the same across many projects, or there is no need to create a standard vocabulary. Consistency is key. What's more, patterns should be accesible by all members of the application development teams, and all members should be trained in their use.
Finally, patterns only provide an opportunity for reuse, not a guarantee. For instance, object-oriented analysis and design methodologies formalize the way we implement reusable elements (objects) where patterns define architectural and design soluctions that we can reuse. There is a difference. Patterns need not be linked to object-oriented analysis, design, and implemntation languages, although this does serve as the majority f their application Furthermore, patterns don't need rigorous notation, a rigid process, or expensive tools. You can just as easily capture patterns on index cards or using a word procesor. The trick is to learn what they are how to create them, and how they fit into your software development life cycle.
One final thought. It seems to me that pattern, as described by the pattern community, are difficult to understand and use. In fact, they are a very simple concept, but the amount of academic double-speak has steered many application architects away from patterns. Hopefully, as with other technolofies with a firm basis in complex theory, we can now release patterns to the masses. It's about time.