title: Flexible design despite strongly dependent classes
body: <p>I'm working on a code which needs to be extremely flexible in nature, i.e. especially very easy to extend later also by other people. But I'm facing a problem now about which I do not even know in principal how to properly deal with:</p>
  
  <p>I'm having a rather complex <code>Algorithm</code>, which at some point is supposed to converge. But due to its complexity there are several different criteria to check for convergence, and depending on the circumstances (or input) I would want to have different convergence criteria activated. Also it should easily be possible to create new convergence criteria without having to touch the algorithm itself. So ideally I would like to have an abstract <code>ConvergenceChecker</code> class from which I can inherit and let the algorithm have a vector of those, e.g. like this:</p>
  
  <pre><code>//Algorithm.h (with include guards of course)
  class Algorithm {
    //...
    vector&lt;ConvergenceChecker*&gt; _convChecker;
  }
  //Algorithm.cpp
  void runAlgorithm() {
    bool converged=false;
    while(true){
      //Algorithm performs a cycle
      for (unsigned i=0; i&lt;_convChecker.size(); i++) {
        // Check for convergence with each criterion
        converged=_convChecker[i]-&gt;isConverged();
        // If this criterion is not satisfied, forget about the following ones
        if (!converged) { break; }
      }
      // If all are converged, break out of the while loop
      if (converged) { break; }
    }
  }
  </code></pre>
  
  <p>The problem with this is that each <code>ConvergenceChecker</code> needs to know something about the currently running <code>Algorithm</code>, but each one might need to know totally different things from the algorithm. Say the <code>Algorithm</code> changes <code>_foo</code> <code>_bar</code> and <code>_fooBar</code> during each cycle, but one possible <code>ConvergenceChecker</code> only needs to know <code>_foo</code>, another one <code>_foo</code> and <code>_bar</code>, and it might be that some day a <code>ConvergenceChecker</code> needing <code>_fooBar</code> will be implemented. Here are some ways I already tried to solve this:</p>
  
  <ol>
  <li>Give the function <code>isConverged()</code> a large argument list (containing <code>_foo</code>, <code>_bar</code>, and <code>_fooBar</code>). Disadvantages: Most of the variables used as arguments will not be used in most cases, and if the <code>Algorithm</code> would be extended by another variable (or a similar algorithm inherits from it and adds some variables) quite some code would have to be modified. -> possible, but ugly</li>
  <li>Give the function <code>isConverged()</code> the <code>Algorithm</code> itself (or a pointer to it) as an argument. Problem: Circular dependency.</li>
  <li>Declare <code>isConverged()</code> as a friend function. Problem (among others): Cannot be defined as a member function of different <code>ConvergenceChecker</code>s.</li>
  <li>Use an array of function pointers. Does not solve the problem at all, and also: where to define them?</li>
  <li>(Just came up with this while writing this question) Use a different class which holds the data, say <code>AlgorithmData</code> having <code>Algorithm</code> as a friend class, then provide the <code>AlgorithmData</code> as a function argument. So, like 2. but maybe getting around circular dependency problems. (Did not test this yet.)</li>
  </ol>
  
  <p>I'd be happy to hear your solutions about this (and problems you see with 5.).</p>
  
  <p>Further notes:</p>
  
  <ul>
  <li>Question title: I'm aware that 'strongly dependent classes' already says that most probably one is doing something very wrong with designing the code, still I guess a lot of people might end up with having that problem and would like to hear possibilities to avoid it, so I'd rather keep that ugly expression.</li>
  <li>Too easy?: Actually the problem I presented here was not complete. There will be a lot of different <code>Algorithm</code>s in the code inheriting from each other, and the <code>ConvergenceChecker</code>s should of course ideally work in appropriate cases without any further modification even if new <code>Algorithm</code>s come up. Feel free to comment on this as well.</li>
  <li>Question style: I hope the question is neither too abstract nor too special, and I hope it did not get too long and is understandable. So please also don't hesitate to comment on the way I ask this question so that I can improve on that.</li>
  </ul>