title: Design pattern appropriate for a modular feature matching application?
body: <p>Since I got some negative comments on my system design on <a href="https://stackoverflow.com/questions/9946135/accessing-a-protected-member-of-a-superclass-typed-member-object-an-elegant-so">this</a> question (concerning the implementation of such system), I hope that if I present the problem I could get some better suggestions.</p>
  
  <p>I am trying to design a modular application to be used for feature matching in video frames (e.g. matching on very close frames of a movie or a video, like "the product" in <a href="http://web.cs.swarthmore.edu/~turnbull/cs97/f08/paper/sivic03.pdf" rel="nofollow noreferrer">this article</a> by Sivic, Zisserman).</p>
  
  <p>The idea is to allow for an easy switch between different <em>feature detection</em> algorithms as well as different <em>matching procedures</em>. Additionally, from my research, my understanding is that there is only a few basic matching procedures, while new matching methods mainly focus on additional pruning procedures for bad matches (e.g. spatial consistency in the <a href="http://web.cs.swarthmore.edu/~turnbull/cs97/f08/paper/sivic03.pdf" rel="nofollow noreferrer">same article</a>). All the pruning procedures require for the initial matching to be done, and then do some additional work on the <em>extracted features</em> from the base and query images <em>coupled by the matching</em>, rejecting the bad matches.</p>
  
  <hr>
  
  <p>The idea I had for the design is as follows:</p>
  
  <ul>
  <li>implement a base interface <code>featureDetector</code></li>
  <li>all concrete feature detection algorithms inherit from <code>featureDetector</code> interface (e.g. <code>siftDetector</code>)</li>
  <li>implement a base interface <code>featureMatcher</code></li>
  <li>all concrete matching methods inherit from the <code>featureMatcher</code> interface (e.g. <code>class bruteForceMatcher</code> or wrappers for OpenCV matchers like <code>cvMatcher</code>)</li>
  <li>implement a base interface <code>imageMatcher</code> implementing a <a href="http://en.wikipedia.org/wiki/Strategy_pattern" rel="nofollow noreferrer"><strong>Strategy</strong></a> pattern to allow for a choice of <code>featureDetector</code> and <code>featureMatcher</code></li>
  <li>for all the matching pruning procedures, implement a <a href="http://en.wikipedia.org/wiki/Decorator_pattern" rel="nofollow noreferrer"><strong>Decorator</strong></a> interface that inherits the base matching interface: <code>class matcherDecorator : public imageMatcher</code></li>
  <li>each additional pruning / filtering procedure implements the <code>matcherDecorator</code> interface (e.g. <code>spatialConsistencyFilter</code>) and contains only the constructor with <code>imageMatcher*</code> as the (only) argument (representing the component to be decorated)</li>
  </ul>
  
  <p>The problems pointed out to me in <a href="https://stackoverflow.com/questions/9946135/accessing-a-protected-member-of-a-superclass-typed-member-object-an-elegant-so">this question</a> arise from the specific results of the feature detection and matching process, and they concern the <em>Decorator</em> part of the design. Each <code>imageMatcher</code> should hold <em>extracted features</em> from both of the images (base and query), as well as the <em>matches between</em> the extracted features. The internal representation of features is slightly different from the feature descriptors offered to the user via the public access function of <code>imageMatcher</code>:</p>
  
  <pre><code>class imageMatcher{
      private: // or protected:
          ...
          ...
          std::vector &lt;internalFeatureDescriptor&gt; feats[2];
              // no more than 500 - 1000 features can be expected
  
          std::vector &lt;std::pair &lt;int, int&gt; &gt; matches;
              // size is the same order of magnitude as the number of features
          ...
      public:
          std::vector &lt;userFriendlyFeatures&gt; getFeatures(int baseOrQuery);
          const std::vector &lt;std::pair&lt;int, int&gt; &gt; &amp;getMatches();
          ...
  };
  </code></pre>
  
  <p>Now, since the feature vectors (as well as the matches vector) are quite "heavy", I <em>would not like to copy</em> them in to each one of the nested decorators (filters) when I use them. I do not have any problems with the <code>matches</code> vector, since it offers a public interface for the user allowing the decorator access to the reference and omitting the need to copy the data. <code>feats</code> vectors, on the other hand, do not offer such an interface, and their access function requires me to do not only copying, but also recalculation of features' internal representation. This in turn results in the need for the decorator to access <em>the private (or protected) variables of the inner superclass pointer</em>.</p>
  
  <p>I managed to grant my self access to the needed vectors without violating any privacy constraints (I (think) I'm not doing anything evil implementationaly), but it has been suggested that the very idea of accessing the private members of the superclass violates the idea of the <em>Decorator</em> pattern.</p>
  
  <hr>
  
  <p>All that said, I am interested in any suggestions about how to refactor my code, comments on my current implementation and anything else concerning the design of my application.</p>