On 5/23/06, Al Boldi <[EMAIL PROTECTED]> wrote:
A pattern is the abstraction of a context problem to yield a general solution.
If you look in a dictionary, you will see that there are two general meaning of "pattern". One is something that is copied, perhaps something that is worthy of emulation. The other is a repetition, i.e. it is as if pattern has been copied even though we know it hasn't, like the patterns of waves on the beach. A pattern in software is both of these. It starts out as a phenomenon that we observe, and we decide that we like it and want to promote it, so we write it down and suggest that people copy it. I do not think that Alexander's statement that "a pattern is solution to a problem in a context" was a definition, rather it was a characterization. Why is something a pattern? Why do we see this technique so often? Why does the old pro tell the newbie "let me show you how it is done"? It is because there is some problem that recurs, and the pattern is a solution to that problem. To understand the pattern, you must understand more than just the solution, you also need to understand the problem. And there are probably other solutions to the problem, so to understand when the pattern is best, you need to understand the context. To me, a pattern is something you have seen before. It is something you expect to see again. Even if you don't know what problem it solves, or even exactly how it works, you can tell it is a pattern. The hard part is not noticing patterns, it is understanding them. It is hard to define the problem that a pattern solves. It is hard to make it abstract enough that it will be widely applicable, but concrete enough that it makes sense. So, noticing that something is a pattern is just a start. -Ralph Johnson _______________________________________________ patterns-discussion mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/patterns-discussion
