Pros and Cons of implementing functionality as functor
<p>I'm having a discussion with a colleague about the API of a simple class that has only one public method. I initially went for:</p>

<pre><code>class CalculateSomething
{
public:
  void operator()(const SomeObject &amp;obj) const;

private:
  // ...
}
</code></pre>

<p>However, my colleague opposes the use of operator() and wishes to simply name the method 'calculate' for the sake of clarity.
Although I don't find that argument convincing, it made me think of the pros and cons.</p>

<h2>Advantages operator()</h2>

<ul>
<li>The class is lean and has a single well-defined purpose. Once instantiated, it basically acts as a free function.</li>
<li>It is a functor and can be easily used as such (e.g. STL algorithms).</li>
<li>When using it with range algorithms, the object can be passed directly instead of through a function pointer, which enables the compiler to inline the code. Although not guaranteed, passing it through a function pointer completely inhibits this possibility.</li>
</ul>

<h2>Disadvantages operator()</h2>

<ul>
<li>It is less clear what the method does without looking at the class name. (I personally disagree as the class has only one method and its meaning is therefore clear from the class name)</li>
<li>Most functors in the STL are expected to be stateless. This I think is the main reason that's holding me back...</li>
</ul>

<p>I was surprised to see that my search on this didn't bring up much since I would assume that this is quite a common scenario (one class, one responsibility). As such, I'm really interested in hearing what other people think about this.</p>