Good design mechanism for exposing class internals to future predicate functors?
<p>I have a class Widget with some private internals, but I would like to expose these internals to predicate functors (only) via friendship.</p>

<pre><code>class Widget
  {
  ComponentA a;
  ComponentB b;
  friend class WidgetPredicate;
  };

class WidgetPredicate : public std::unary_function&lt;bool, const Widget&amp;&gt;
  { 
  bool operator () (const Widget&amp; w) const
    {
    // inspect a and b and make a yes/no decision 
    }
  };
</code></pre>

<p>The intent is that I can use the WidgetPredicate function as a sifter in all the std::xxxx_if family of algorithms.</p>

<p>However, I would like to leave some extensibility in the system where a future developer could make new predicates that somehow inheirit the friend status neatly. Is there a good design idiom for this? My current (non) solution is that everything in Widget is public. </p>

<p>I tried toying around with a base class that exposed the internals of Widget to subtypes of WidgetPredicate through protected functions, something like:</p>

<pre><code>class WidgetPredicate : public std::unary ...
  {
  protected:
    const ComponentA&amp; expose_a ( const Widget&amp; w ) const { return w.a; }
    const ComponentB&amp; expose_b ( const Widget&amp; w ) const { return w.b; }
  public:
    virtual bool operator () ...
  };

class DerivedWidgetPredicate : public WidgetPredicate
  {
  public:
    virtual bool operator () (const Widget&amp; w)
      {
      const ComponentA&amp; a = this-&gt;expose_a(w); // a can now be inspected/predicated upon
      const ComponentB&amp; b = this-&gt;expose_b(w); // b ...
      }
  };
</code></pre>

<p>I can live with the potential that now any class could examine Widget's internals just by saying :public WidgetPredicate. I am not trying to protect against malicious developers, so if they say they're a friendly WidgetPredicate then I am willing to take that at face value.
The syntax is also subpar, but I can live with that too. What I don't like the maintainence issue, that when I change the internals of Widget I have to also add new expose() methods to the base predicate. (IMO That process could and should be mechanical). </p>

<p>I could always put the expose methods directly in the Widget class, but IMO at that point I might as well make the fields public and just live with it (ie my current soln).</p>
