Why Patterns Are Different Why Patterns Are Different
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 solutions. 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." (TimelessWayOfBuilding, 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.
HandsInView 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 situation.
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 with RichardGabriel, 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 combination. 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." (TimelessWayOfBuilding, 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 design phase 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?
Just wondering...
-- StanSilver 8/30/96
Hi, Stan,
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 architecture to what we call implementation. 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 DesignIsNotaDevelopmentPhase. Design is the whole job; patterns are relevant to design.
That said, I think there are many effective WaysToUsePatterns.
-- JimCoplien
Hello,
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, PatternLanguagesOfProgramDesign, AdvancedCeePlusPlusProgrammingStylesAndIdioms (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
This page mirrored in WikiPagesAboutWhatArePatterns as of April 29, 2006