FREE Subscription to Dr. Dobb’s Digest: Same Great Content, New Digital Edition
Site Archive (Complete)
Architecture Blog: Patterns
Architecture & Design
PATTERN LANGUAGE

Modeling, Managing, Making it Right.

by Jonathan Erickson
IF YOU BUILD IT

... Will they Come?

by Arnon Rotem-Gal-Oz
March 09, 2007

Patterns

While waiting for feedback on what you think about architects vs. project managers, I thought I'd talk a little about patterns.

Recall that I'm writing a book on SOA patterns. I was speaking with a friend who asked why did I choose to document the SOA solutions as patterns. I told him that patterns seems the natural way to do that, but when I thought about it a more I came up with something a more structured.

The main reasons I see for using patterns to describes describing solutions using patterns are:

  • Patterns have a name. This may not sound like much, but you can use names to communicate what you're trying to do. If the patterns you are using are common (or common within the group you work with), then using this name can make your communication smoother.
  • Patterns have context. We all know there's no silver bullet (right?), so documenting a solution is not enough -- you also need to say when it is applicable. When you document a solution template with a pattern you also explain where it can be used. It can get even better if you also document when not to use the pattern. Patterns are "good practices" not "best practices".
  • Patterns have consequences. I've said before that the secret of great architects is that "it always depends". The trick is to know to analyze the trade-offs of the various options. When you document a solution as a pattern you also explain what does it mean to use this pattern and the implications or consequences of using it.
  • Patterns are related. A single pattern is usually related to several other patterns. Some patterns can be alternatives other can be complimentary and sometimes other patterns are the opposite (but they solve well other issues). Having these relations documented to construct what is known as a "pattern language" can really be a boon. For instance, youcan look into complimentary patterns and combine them to create integrated solutions for bigger problems. Or you can weigh alternatives by considering the consequences and context of related patterns.

The downside of patterns is that when you have too many of them and locating one that fits your situation can be difficult. Grady Booch has almost 2000 of them cataloged on his site (registration required), but it is still hard to locate the one pattern you want.

The other thing is that patterns are difficult to write. I just took a look at the first drafts of some of my patterns (posted on-line) vs. the current drafts of the same patterns and I see how difficult it was, but at least it is also very rewarding :)


Posted by Arnon Rotem-Gal-Oz at 05:06 PM  Permalink




 
INFO-LINK