Pattern Solver

A PatternSolver is an algorithm based approach to finding the optimal pattern.

Like expert system, where context is used to determine the optimal patterns to use. The ladder sort of solves to the most correct solution. The developer can then modify the "generated patterns" as necessary. There currently exists no PatternLadder, it may not even be possible to create one. A network(perhaps as ConceptMaps) could be created though. However, it is not assumed that the best design must start with a catalogued pattern. The developer is free to "gather possibilities" and then create/choose as appropriate. Also consider that such a system could choose a better catalogued pattern than many LarvalProgrammers? could create from scratch. Isn't that the point of patterns? To choose for pre-found solutions? --LayneThomas

Why this is a bad idea: It assumes the best design for your app must start with a catalogued pattern, and it assumes that starting with that design, then adding its behavior, is a GoodThing.

The design of your object model bows to its behaviors. These bow to their tests. So, use TestDrivenDevelopment to write the tests first. Perform the minimal edit possible to make a test pass. If the minimal edit clones an entire module and changes one line, do it.

The book DesignPatterns says to abstract the thing that varies. This is the opposite way to say "find a good object model by merging duplication." After the tests pass, merge duplication back out of those cloned modules, until only the lines that differ remain, abstracted away from the common elements.

The above process is a sieve to find a good "pattern" for an object model. But it has the added benefit you can do it incrementally, under test, and it will find object models that are not catalogued. The authors of the patterns books are not the authority. Your tests are the authority. --PhlIp

I have never understood the resistance to formalizing patterns. The argument seems to be "I am a strong programmer, so patterns are irrelevant as the best solution will always be a hand-crafted custom fit". That directly conflicts with TheBestIsTheEnemyOfTheGood. Also, the benefits from having a not-quite-optimal solution based on a common pattern language all developers(including larval) can understand seem quite high. That, and a pattern solver tool doesn't have to be rigidly followed, it's just a tool, and can be used however the developer sees fit. --LayneThomas

I have never understood the resistance to things I did not say. A Pattern can be a goal, but should not be the path. Read RefactoringToPatterns by JoshuaKerievsky. Can you back up that statement? I see nothing in RefactoringToPatterns referring to "be a goal, not a path" Joshua was not the authority I appealed to. --PhlIp

When I was young playing with Legos, my goal was never to use a lego block. It was always to build a spaceship/city/whatever. However my creation was built from the modular blocks. I always saw patterns as lego-like blocks - the alternative is to melt and mold your own plastic for every little thing. JimCoplien posted in FormalMethodsAndPatterns a poetry analogy. However many kinds of poetry are rigidly formal(haiku, iambic pentameter, etc) - and poetry is still categorized in the library. Just because the poetry itself isn't necessarily formal, doesn't mean it can't have formal properties -- LayneThomas

Oh, we want to talk architecture, huh? Read NotesOnTheSynthesisOfForm by ChristopherAlexander. He's the guy who invented PatternLanguages. --PhlIp

Interesting notes, however he seems to be discussing BigDesignUpFront versus AgileMethodology, not arguing for or against a pattern solver system. The solver system could easily have concluced "an agile iterative method is the optimal route". Could you post your argument directly, instead of indirect references? -- LayneThomas

Again: Duplication removal is the "PatternLadder" you request. --PhlIp

Ok. I think I see what you are saying. Namely one ideal way to find the optimal pattern is to write the tests and prototype, then OnceAndOnlyOnce the duplicate code until a pattern/abstraction emerges. That is a good evolutionary way to develop/find/refine a pattern.

However the evolutionary method misses some points:

The pattern finding method is a pattern itself and could be recorded in a PatternLadder as a solution to a problem.
Patterns are not limited to coding techniques. Methodologies, architectural patterns, even social patterns could all be put in a pattern ladder.
Evolutionary design is not the only design method. It is still necessary to weigh various approaches, as no pattern or approach is unassailable, it would be helpful to have a semi-automated balancing system instead of just a huge collection of patterns that must be weighed manually with all the other patterns.
If every pattern naturally evolved when it was needed, there is no reason to document common patterns at all, they would simply arise when needed. That means this entire Wiki is useless as every pattern in it would be extraneous.