Hitchhiker's Guide to Software Architecture and Everything Else - by Michael Stal

Monday, March 08, 2004

What is a Pattern?

Yes, I know that everyone knows what pattern are these days. This question however is not supposed to address the fundamental definition of patterns. It is more an issue dealing with the validity and lifetime of patterns. As we mention in our POSA series patterns are not carved in stone. They are subject to change and extension. Just assume for a moment that you have documented a pattern like Singleton. After several years of practical application new implementation contexts have been found by developers that were not anticipated in the orginal pattern description. In addition, assume errors were detected in the pattern documentation. Now consider the case someone else is re-documenting the pattern according to these findings. Which kind of changes will modify a pattern in such a way that you should consider the pattern re-design to be a new pattern of its own? When is it allowed to assign an already existing pattern name to a re-designed pattern description? My first guess at the moment is: when errors in a pattern description are removed this won't qualify for considering the result a new pattern. The same holds for providing new forces, consequences, or known uses. Obviously, just adding a new example won't affect a pattern so that it becomes a new pattern. If someone comes up with a narrowing of the pattern application scope - take remote proxy as an example - this will lead to a new pattern variant but not to a new pattern. If however, the internal structure or dynamic behavior of a pattern is changed in a significant way such as removing or adding participants without narrowing the pattern's context this will qualify to consider the new pattern document as a new pattern of its own. This, of course, as always in the pattern universe, only holds if there are at least three known uses. Using the same pattern name in this case would inevitably lead to confusion, because people applying the pattern would talk about the same pattern name without referring to the same pattern content. This way, we would loose one of the benefits of patterns as an architectural concept. Now, for something completely different. Guess, someone has documented an architectural pattern. After a while other architects document a pattern language to help implementing the architectural pattern. Does this qualify for re-documenting the original pattern? From my viewpoint it does if the pattern language is just applied to add meat to the pattern implementation section. In this case architects should be aware of the fact that architectural patterns by nature denote generic patterns applied to complete software architectures. Since they are cover such a high abstraction layer, it is obvious that each architecture pattern represents a root from which complete pattern languages can be derived. There are two points to consider. If the pattern language does narrow the focus of the architecture pattern or change its static structure or dynamic behavior, the result is a completely new pattern or variant. It is not just an implementation of the existing pattern anymore. The other issue to be taken into account is the fact that the same architectural pattern might even be implemented using different pattern languages.
So what are my conclusions? Patterns live. They are actually not carved in stone. Error modifications, widening of scope, additional known uses, additional or modified implementations or example sections, additional forces and consequences should be possible without having to instantiate a new pattern. All other changes affecting static structure or dynamic behavior in a significant way lead to a new pattern of its own that must be associated with a new pattern name. There are still some open issues here. Hopefully, future discussions will shed more light on this discussion.