As I understand it, the patterns in a PatternLanguage are organized in such a way that the solution of one pattern forms or influences the problem statement of one or more following patterns.

If this is true, what could be called a "reasoning tree" is formed by stating or summarizing the _solutions_ of these patterns in an indented tree form, perhaps also referencing the name of the patterns.  The solutions seem to be best stated as declarative statements.  Note that extra reasoning steps sometimes need to be added to the concrete patterns (in the example below, concrete patterns are referenced in brackets).

I have found that reasoning trees are often a good way to "reverse engineer" the pattern language author's reasoning.  Has anyone else found similar structures useful??

Example:

   Write software cost effectively
      Write easy to maintain software
         Write easy to change software
            Use well factored designs
               Assign one class per major responsibility
               Assign minor responsibilities to correct classes
                  Pull, don't push [Pull don't push]
            Use well factored methods
               Only write code once [Write it once]
               Use "one task per method [One task per method]
                  Use query methods [Query methods]
                  Use compound methods [Compound methods]
         Write easy to understand software
            Put a comment in each class [Class comments]
            Put a comment class in each subsystem [Comment class]
-- StanSilver

-----

Yes, I have tried this.  My attempt showed up in the PLOPD 2 book (PatternLanguagesOfProgramDesign, vol 2), as "Prioritizing Forces in Software Design." Its successor, SocialIssuesInSoftwareDesign, is now on my web page as "Social Issues in Software Design" (http://members.aol.com/acockburn/papers/softorg.htm). 
I find that not many people actually work to such a reasoning tree, but that tree helps to follow someone else's reasoning.  One of the harder bits is that reasoning makes a graph, not a tree. -- AlistairCockburn

This looks like a great way to organize the table of contents for a pattern language and perhaps even to find holes in such a language. The latter would be facilitated if each solution carried with it a list of problems.

Would it be possible to write a language independent reasoning graph? PatternPrimitives started as an attempt to see how microscale a pattern could be before it vanished into code details. Would it be possible to take the primitives mentioned there and draw a tree that was valid for any functional program, if not, is it because there are primitives missing; or that the idea is unworkable?

-----

I did something very similar, justifying various business strategies and actions based on goals and values. We also categorized statements into four "abstraction" levels -- but this proved less useful than the directed links between statements. Yes, we ended up with a directed network (not a hierarchy), with no loops. -- JeffGrigg

See "Figure 1.1: Design pattern relationships" in the DesignPatternsBook, which 'organizes design patterns according to how they reference each other in their "Related Patterns" sections.' ''(It's not a hierarchy.  And, surprisingly enough, there are no loops in the diagram.)''!

-----
CategoryGroupsOfPatterns