How do you know when to use the PatternForm to describe a particular solution/problem/forces relationship? If there is a particular principle or problem/solution pair that can be documented, when is pattern form appropriate? For instance, ChangeOfSetting describes a problem, has a context and forces involved, and suggests a solution. But should it be a pattern? As another example, consider the principle-pattern WhatYouProduceTheyConsume. Is this a pattern, or just a principle or idea in pattern form? Maybe there are (or should be) definitive criteria for concepts suited for pattern form. What do you think? See also: PatternFormsTakeSomeGettingUsedTo ---- A criterion based on the number for significant forces at play may be a good starting point. Here's a first approximation: '''Principle:''' Do X '''Advice:''' If A then do X '''Pattern:''' To balance f(A, B, C, ...) do X There's nothing to balance in the first two cases, so the "solution" can be stated simply. The third case benefits from using a pattern form, particularly in describing the forces and their interplay. -- DaveSmith ---- SwieringaAndWierdsma call the second level single-loop learning, the pattern level, double-loop learning, and they describe a further level called TripleLoopLearning. ''(More thoughts there)'' -- JimCoplien ---- I would suggest this checklist to determine whether something is well-suited to pattern form: * It must be a solution to a problem in a context * You must be able to tell the problem solver what to do, how to solve the problem * It must be a mature, proven solution (RuleOfThree) * It must contribute to human comfort or quality of life * It must be something you didn't invent yourself (BuschmannsLaw) * The solution should build on the insight of the problem solver, and can be implemented a million times without ever being the same twice * It cannot be formalized or automated (if it can be formalized or automated, then do that instead of writing it as a pattern) * It should have a dense set of interacting forces that are independent of the forces in other patterns Writing a pattern should probably be hard; if it's too easy to write, it may not be a pattern, or you haven't thought hard enough about the forces. -- JimCoplien I think your points are either to strict or too much inspired by the original architecture pattern ideas of ChristopherAlexander. Especially "human comfort or quality of life" and "a million times without being the same twice" will hardly apply to any software pattern. -- HelmutLeitner Also, you can use the Pattern ''form'' without writing a Pattern. I call these things Resolutions for lack of a better name. They ''resolve'' the forces. They mainly differ from Patterns in that they aren't ''patterns''; that is, the three (or whatever) examples are missing. -- SunirShah ''See also IdeaForm.'' ---- I thought about this overnight, and came back to add some thoughts, only to find that Cope had not only hit most of my meager additions, but had also significantly raised the level of discourse. Wiki is indeed a wondrous place... Coming at Patterns from SystemsThinking, my bias is to use patterns to capture descriptions of portions of systems, the forces that play in those parts, and what experience has shown about leveraging or balancing the forces to achieve either growth or stability. We're often unaware of the larger pictures (systems) that we operate in, and patterns can help both to reveal previously unknown forces, and to shed new light on the significance of those forces. Or, to paraphrase Cope, the pattern should lead to new insights about the dense interacting forces within the context. A criterion that I wonder about is ''simulatability.'' It should be possible to simulate, if not predict, the outcome of applying the pattern in a given situation. Inability to simulate may suggest that either there are forces in the context that are yet to be described (i.e., the pattern is incomplete), or that the proposed solution isn't amenable to pattern form. Consider Alexander's patterns: many can be simulated by building scale models. Cope's final bullet is problematic, since it is often difficult or impossible to separate or isolate a subsystem from its larger system. or to manipulate the subsystem without causing ripples. I think that it's enough for the pattern to suggest what those ripples might be, and to refer the reader to related patterns. -- DaveSmith ---- In JourneyOftheSoftwareProfessional, LukeHohmann writes: "Although patterns have great value, not every plan should be elevated to pattern status. First, many plans are idiosyncratic to a problem domain or specific solution. The true value in a pattern lies in its applicability ''across'' many problems. Second, many plans represent simple semantic-syntactic knowledge and should thus be considered a part of the core knowledge about the domain of software development ''all'' developers should share. The concept of a subroutine is not a "pattern" for solving a range of problems. It is instead a core piece of knowledge required for effective use of almost any programming language. Third, it does not make economic sense to expand the effort to 'patternize' every plan inside our head; the payback is simply not there. Finally, the existence of a pattern solving a problem only has value if you know it! I'm not yet convinced the best strategy for problem solving is searching through hundreds or thousands of patterns in search of ''the'' pattern meeting the exact requirements of the problem." [p. 7] -- DaveSmith ---- CoreKnowledge takes time to learn. I find that a lot of core knowledge goes unnamed. But I also find that attaching a good name to a piece of knowledge helps me to remember it, which helps me eventually come to ''own'' it. Ofcourse, having names also makes it easier to communicate with others. So perhaps these folks who are writing patterns that aren't actually patterns are really just trying to describe a new vocabulary? -- JoshuaKerievsky I think you're definitely on to something Josh. Its still too fuzzy for me to articulate though. Id love to see you expand on it if you have the time and the inclination. -- BradAppleton Thanks for the encouragement Brad. I've actually made some good progress on articulating these ideas (and others related to the form of knowledge) in a pattern language I'm writing. I hope to have a version of it out in a month or two. ''I would define Core Knowledge as the recognized basic patterns (Core Patterns) you aquire when learning. For example, the patterns of what a person looks like, what is a circle, etc. are core knowledge to the human race, but you probably aren't born with that knowledge either. A child is still taught these core patterns and everything they do in life builds upon them -- WyattMatthews'' ---- CategoryPattern