FAQ from Bruce Anderson's group at ChiliPLoP'98, Wickenburg AZ, 17-20 March 1998
These questions were saved up on a flipchart, and answered at the end by myself and Don Olson; this is our improved version. In each case the first part is my answer, based on ideas from Don and myself, and often there is a comment or expansion by Don. Thanks also to Linda Rising who assisted the group on the first day.
What is a design problem?
Bruce: Donald Schön talks about "design-like" professions, where the practitioner is always inventing something (in the small) to advance the situation with the client. A line of code is "no big deal" but it may be unique in the universe! Similarly with how a pianist plays a note, or what a therapist says next. Schön talks about "dialogue with the situation" to emphasise the improvisation needed. Any "designer" could (try to) capture some of their skill in a pattern language. Notice that you still need to improvise when using patterns, but they certainly narrow the scope.
Don: In design problems we are always trying to determine what responsibilities exist, where they lie, and how one affects another. The area of where responsibilities collide and affect one another is where patterns can provide the most value, because patterns are a way of characterizing relationships and examining collaborations. But the dynamic nature of this area of design requires an iterative, conversational interaction with the problem space.
What are "pattern languages" vis-a-vis "pattern systems"?
Bruce: These are simply different terms for the same thing. The term "pattern language" is confusing as it isn't clear where the language is, how meaningful things in it are made up, or what they mean. I like to say "system of patterns" or "interlocking set of patterns".
Don: In many pattern languages, the systemic aspect is clearest where they can be connected by following the resulting context of one pattern into the context of one or more others. This is what makes a system of patterns most useful in the real world.
What is the definition of a pattern language?
Bruce: Perhaps there isn't a definition, just explanations appropriate to the context of the question. I usually say "A pattern is a solution to a problem in a context. A pattern language is a collaborating set of patterns that operate in a domain of problems" at some time, but before that I present examples, and before that I want to know why the questioner is asking.
Can the definition of pattern languages be standardized?
Bruce: Not usefully, except by a collaborating team in a context who can reach a constructive agreement.
How is a pattern different from a good written solution to a problem?
Bruce: For the pattern user, remember that a pattern is one of a set, and so provides a solution to just part of the whole problem, and guides you as to where to work next. It discusses forces explicitly, giving you a chance to tailor the (partial) solution if the forces are different in your specific case. For a pattern writer, the form provides a useful discipline, a proven path and a link to the community.
Don: Think of patterns as a literary form of expression. As in poetry or prose, there are many forms, each form being suited best to certain kinds of expression.
When is a problem-solution pair a pattern?
Bruce: Here are the generally agreed objective criteria: three or more examples exist; it follows a form; you didn't invent it!
How do patterns serve the refactoring and reengineering of legacy systems?
Bruce: You could use a pattern language to describe your chosen approach. This might be developed in-house, or you might be able to work from someone else's. Alan O'Callaghan has some patterns for dealing with legacy systems. Only fairly mature operations can use pattern languages (or any other form of handbook) consistently, and immature ones may find them too onerous, ditch them in panic, or fail to maintain them.
Don: The beauty of patterns as a means to refactoring legacy systems is that they are precise enough to preserve hard-won domain-specific knowledge but "loose" enough to allow its future reimplementation in related but evolving areas. They are like clothing that fits well, looks good, but allows for some weight changes over time.
Use cases are tied to object models. Components seem to relate to patterns. How do these pairs tie up?
Bruce: Well, there are lots of design aspects here, and patterns could be used to help with (and discipline) all of them. A pattern language can be an explicit set of agreements as to how problems are solved by a community - "here at Andersen's we do it this way" - so, for example, they could suggest which component to use, or which use case to suggest.
How do patterns relate to Methods, Standards, Templates and Frameworks?
Bruce: Well, it rather depends whether your problem is "deliver software to do X" or "deliver software using method A, standard B, template C and framework D to do X"! In the latter case you clearly have a (set of) design-like problem to solve, and can have patterns for it. The former case is harder, since you have to think about what really needs doing. You could find, develop and augment patterns that gave just the right amount of guidance and structure for effective delivery and maintenance. Ward Cunningham has some challenging patterns about this. Ideally, the approaches would converge on what really needs doing in your context. Personally I'm just recovering from a client context where the prescribed method had too many deliverables for the easy bits and too few for the hard ones!
Don: In line with this experience, patterns are very valuable in forcing one to think all the way through a problem space, because in each resulting context will be revealed problems as yet uncovered by the pattern language. Until you can comfortably handwave the remaining odds and ends that show up in all the resulting contexts of the patterns in a pattern system, you're not done. Too often in object modeling we tend to detail those things we understand and generalize those we don't because the modeling techniques let us get away with it. Patterns are not so forgiving in this sense.
Can patterns be used to help solve abstract problems?
Bruce: Yes, problems and patterns are concrete at their own level. For example, deciding the architecture of a large distributed system is an abstract problem, yet the resulting structure must be buildable. A professional architect can see how that building is possible, and can guide those who take the structure down to the next level of detail i.e. can help those whose job it is to make a problem of his solution. To quote Mary Shaw "there is only design".
So if I could just understand how to have Dialogue With The Situation and could figure out what a Problem Space is, I might be able to Detaila Solution using the Domain Knowledge in the Resulting Context of the Related Evolving Areas and then come up with something that works!
See original on c2.com 