Design Pattern for executing requests on different "output levels"
<p>I am parsing a string like:</p>

<pre><code>\read(customer) hello world


~&gt; \method(arg, arg, ...)
</code></pre>

<p>into a <strong>composite data structure</strong> that persists of <strong>1</strong> to <strong>n</strong> arguments, which are <strong>requestLeaf objects</strong>, which arguments can be a <strong>requestLeaf object</strong> (if it's just plain text, that should be returned like above ("hello world")) or another <strong>requestComposite object</strong> (if there is some computation going on(like read->customer) until it's just plain text again.</p>

<pre><code>requestComposite Object
(
  [requests:protected] =&gt; Array
      (
          [0] =&gt; commandRequest Object
              (
                  [methodName:protected] =&gt; read
                  [arguments:protected] =&gt; Array
                      (
                        [0] =&gt; commandRequest Object
                          (
                            [methodName:protected] =&gt; text
                            [arguments:protected] =&gt; customer
                          )
                      )
              )
          [1] =&gt; commandRequest Object
              (
                  [methodName:protected] =&gt; text
                  [arguments:protected] =&gt;  hello world
              )
      )
)
</code></pre>

<p>What I want to achieve is to loop through the whole composite so that it renders some kind of document.</p>

<p>The arguments or <strong>leafs</strong> of the very first <strong>composite</strong> are representing the <strong>root</strong> or Level 0 for printing to the document.<br>
I want to use a Library for this. This library can handle printing text, images, etc. but cannot evaluate anything!</p>

<p>Everything <strong>> Level 0</strong> should be computed in <strong>another</strong> library.<br>
This library can read member values, do some math, etc. and return its final value (exclusively strings) to the <strong>root</strong> to be printed out.<br>
Everything else is printed explicit via e.g. \img() or \text()</p>

<p>There may be a</p>

<pre><code>\read(x)
</code></pre>

<p>token to lookup a member value X,<br>
whichs value should be printed implicit, <strong>(without wrapping it into another \text())!</strong></p>

<p>there may be a \list() token to loop its arguments through a specified member list like:</p>

<pre><code>\list(\read(x)))
</code></pre>

<p>X could be another Y</p>

<pre><code>\list(\read(\read(y))).
</code></pre>

<p>In other words: <strong>I cannot know how deep the structure will be.</strong></p>

<p>Happens that I'm fairly new to Design Patterns and OO in particular.<br>
I am fiddling around with the <strong>Chain of Responsibility</strong> Pattern for "executing" right now, where the <strong>rendering/output</strong> library and the <strong>computation</strong> library are building the handler chain.<br>
But I'm somewhat curious about if CoR really fullfills my needs:</p>

<p>How would you solve a problem like this?  </p>

<p><strong>EDIT: MY APPROACH AS FOR NOW</strong>  </p>

<ol>
<li><p>to iterate through the composites.<br>
passing along a <strong>Mediator</strong> Object<br>
which contains the <strong>output library</strong> and the <strong>computation library</strong>.</p></li>
<li><p>if <strong>current leaf</strong> is text<br>
check if current is the root<br>
if NO <strong>visit</strong> the computation library to evaluate the actual value and pass it to whom it may concern (e.g. \read(), \varput(), ...)<br>
if YES <strong>visit</strong> the output library to print it out</p></li>
</ol>

<p>What comes to my mind is that I have to implement every requestMethod in both libraries to achieve the automatic root printing. i.e.<br>
\read() in <strong>output</strong> should print text to the document,<br>
\read() in the computation library should lookup a member value.</p>

<p>Am I overcomplicating things here?</p>