...from other design disciplines.
Patterns solve problems:
Many design methods strive to uncover the structure
of a system; most focus on the structure of the solution.
Those that focus on the structure of the "problem" use
the word "problem" only in the loosest sense.
Patterns are explicit about the problems they solve,
and about the solutions they provide. A pattern is not
a strategy, but a problem/solution pair. A pattern
may attack a problem that is abstractly stated, but
"abstract" never means "vague."
Patterns are generative
Most problem-solving techniques pair problems with
In complex systems like software programs, the problem
and solution are often not close in time and space.
That makes it difficult to methodically hunt down
solutions on demand.
But insight, cleverness, or luck uncovers such
solutions over time. Patterns chronicle
such solutions. Alexander said, "This quality in
buildings and in towns cannot be made, but
only generated, indirectly, by the ordinary actions
of the people, just as a flower cannot be made, but only
generated from the seed." (TheTimelessWayOfBuilding
, p. xi)
I think we should leave non-generative solutions in the
able hands of FormalMethodsPeople?
People talk of FormalMethodsAndPatterns
; by the
time technology or understanding matures to the
point where we can formally capture an idea, it
ceases to have the generative, literary quality
that sets patterns apart from other methods.
is a great generative pattern. See GenerativePattern
Patterns build on experience
Most design methods create new structures from first
principles; while the principles are well-known, their
application to a given context isn't proven, and the
resulting structure may be entirely novel, and perhaps
unsuitable to the problem at hand. It takes insight
to apply a method to a problem; in fact, it takes insight
to choose the right method. Patterns encode experience
by documenting proven structures, and how they relate both
to the underlying principles, and to the problem at hand.
They convey not only the solution,
but the insight behind it.
Patterns both build on the experience of those
who refined the idea over time, and on the experience of
those who insightfully apply the pattern to a given
Patterns focus on aesthetics and human comfort
Most design methods focus on the needs of the computer,
or on principles like CouplingAndCohesion
However, the computer doesn't "care" about its
coupling and cohesion, and most design methods don't
make it clear how their mandates improve the quality
of life. Good patterns tell how humans benefit from
their application. RichardGabriel
says: "We are trying
to bring people and humanity into the software design and
development process. I think this is the goal because
it's the key Alexandrian idea. If you look at his
patterns, each or nearly all talk about the context and
forces in terms of what people need to do to live
fully and to be fully alive..." (Personal communication
, April, 1995)
Dick wrote a simple example of a software pattern with
strong human overtones, called SimplyUnderstoodCode
Patterns address the "orthogonal" dimensions of design
Object-oriented design produces objects.
The object paradigm is a good decomposition and abstraction
technique, but it is weak for integration. The same is true
for top-down procedural design (which was why reuse was
so hard with procedures). Good patterns cut across the
modular parts of design and address the important constructs
of system structure. Alexander says:
"Design is often thought of as a process of synthesis,
a process of putting together things, a process of
According to this view, a whole is created by putting
together parts. The parts come first; the form of the
whole comes second.
But it is impossible to form anything which has
the character of nature by adding preformed parts.
When parts are modular and made before the whole, by
definition then, they are identical, and it is impossible
for every part to be unique, according to its position
in the whole." (TheTimelessWayOfBuilding
, p. 368)
Jim - You compare patterns to other "design methods" and "problem-solving techniques" in this discussion. That got me thinking. Up to now, I have used patterns to record problem solutions (and to read about other people's solutions). In other words, for education purposes. I like patterns a lot.
I have never really thought about the best
way to use these patterns in a new project - I guess I have just assumed they would be talked about during the DesignPhase
and somehow make the process go smoother.
Do you have any advice about explicitly using patterns in a software project? Or any project involving design? Are there any "patterns" about the best way to use patterns in a project? Do they work best in design reviews? Code reviews? Should which patterns to use be decided on by the whole team up front? Or are they just used for education, with the assumption better educated designers and coders will produce better projects?
I don't think there is a "best" way to fit patterns
into a development process or method.
Patterns cover development problems
that range from what we call
to what we call
We also have patterns of testing; I can conceive
of patterns for maintenance; there are those who
have published AnalysisPatterns
Patterns are just a problem-solving tool,
and software developers face problems at all levels.
I also wonder what you mean about "design phase."
As I've done empirical studies of software organizations
worldwide, I quickly discovered that
Design is the whole job; patterns are relevant to design.
That said, I think there are
many effective WaysToUsePatterns
One, perhaps the principle, way I use patterns during
design (and BTW: Yes, design occurs throughout development. But it is also true that it is more intensely involved in the beginning of a project than the end) goes like this: I get a whole bunch of potential objects. I think about them, make a few preliminary stabs at "clustering" them (sort of like modules) and see if I can get a decomposition into a whole bunch of modules (each of which will have a Facade) and some very tightly defined lines of communication (this is a goal).
Now, within each module, there's a whole mess of related objects, which seem pretty related. I look at the interactions and then go skim DesignPatternsBook
(not as often, as I don't do C++) etcetera.
A lot of times, things just click. I look at my objects and I think ooops. That's the wrong model because of
x and I think GOF got it wrong too (for this circumstance). But, there's something
close which feels right.
I make it a point, whenever I'm sketching out a set of objects that are closely related, to go and read a few patterns, to see if anything clicks.
I think that someday I will make up a formal checklist of questions ("if you answer yes to this question, think about using the following patterns....") arranged about core
objects. But, I think patterns will have to have settled down a bit more before that's really possible.
Your thoughts here