| Random Page
lists a number of different forms that have been suggested as a framework to describe patterns, especially software patterns. One should compare this to the latest works of Christopher Alexander, and adapt this to the wiki needs.
One could start with the minimum subset of Wiki:CompactForm:
(example under construction, it's not that easy because PatternForm and PatternLanguage are intermingled)
) / for reuse take WikiPatternFormTemplate
- Pattern Name: PatternForm
- Context: SystemTheory done by ChristopherAlexanders PatternLanguage methods. This is about complex structural systems that interact with humans or other living creatures, like city architecture, music, software architecture or online community structures. Understanding such systems and their interaction with the living actors is essential to improve our ability to build or grow such systems. Economic interests often lead to bad decisions serving more commercial interests than the life within these systems.
- Problem: One needs a systematic approach when writing down a PatternLanguage.
- Forces: The complexity and natural disorder (entropy) makes these system difficult to understand and describe. Often we lack the language for the descriptions. Short noun phrases often take the place of missing words, form a languages and are used to label the patterns.
- Solution: Observe the systems and look for recurring and useful elements. Give them names and understand their relationship to other elements. Understand the context and the forces. Such patterns will be reusable in many different ways. The description of patterns may take the form of a database entry using a PatternForm. The PatternForm helps with a systematical approach and helps to understand what patterns are.
- Implementation level: In the wiki the PatternForm is usually a section of a wiki page that describes and discusses the pattern and its application. The pattern name is usually identical with the wiki page name.
- Resulting Context: A better understanding of the systems. Patterns are extracted, often from years (in architecture millenia) of experience and over time form a PatternLanguage. Together with the functional aspects, the forces and the actors a rich networked model for understanding and building living systems is created.
We could extend it - when needed - by taking parts from Wiki:BradAppletons Wiki:CanonicalForm:
- Pattern Name
- Resulting Context (also "Resolution of Forces")
- Rationale [if needed]
- Sample Code
- Known Uses (sometimes this is part of Examples, or vice-versa)
- Related Patterns
Good examples of PatternForm use:
Doubtful examples of PatternForm use:
My preferred style is Ward's Wiki:ThereforeBut. The field-by-field breakdown description of Patterns seems rather antithetical to the entire concept of Patterns in the first place. A Pattern (or Resolution, as I call Patterns without examples) should feel when read just as it is in the world: the full set of conflicted forces all bearing down on the problem, that through the BalancingForces compel the resolution of those forces at the apex of the Pattern, which then result in new forces unleased spreading out into the world. That is, it should have an hourglass rhetorical shape, where the actual Pattern itself is the neck of the hourglass, and the sand are forces, and there is a sense of gravity pulling the sand through the neck from one bottle to another. -- SunirShah
I can't agree with "antithetical" because its a way that ChristopherAlexander suggested and used. When people become euphorical about patterns and want to find, invent or push their views, then these pattern forms with their weak content look worse (http://www.openpeople.info/index.php/MinciuSodas/KeyConcept) (ed : BrokenLink, perhaps should be ?) than if they had just expressed their ideas. In fact the form content above is also bad (or let's say "under construction") because there is a mix-in of the PatternLanguage pattern (but this is maybe only defined in the context of SystemTheory).
Wiki:ThereforeBut is maybe a general rhetorical pattern, but it is not in a direct relationship with defining a pattern. You can use it for a lot of different purposes. I think the big problem with patterns is: to know what's not a pattern. An algorithm, for example, is also a solution to a problem, and one could describe it in a pattern form or a Wiki:ThereforeBut, but an algorithm is not a pattern. Alexander, as an architect always looks at patterns as structures in space, so I still don't know what they do with yazz music patterns for example, or whether we can really do "user role patterns" which seem to lack an geometrical aspect. -- HelmutLeitner