NOTE: I found this in my drafts folder, from a long, long time ago, it’s a little dated but I will let it stand as some of the points are still valid.

At work I’ve inherited several legacy projects, one large with several smaller ones that support it. Making changes is pretty dangerous – I’ve been bitten a few times by a seemingly innocuous change that has only come to light during testing. The way I use the application as the developer and the way a service engineer uses the same application is different.

So I started writing unit-tests (UnitTest++ retrofitted to work with VC6) to test my assumptions and make sure that my changes don’t break things. A major problem is testing private functions. Some can be fixed by promoting private to protected, inheriting the class and then adding testing hooks in the class. Like:
[sourcecode language=’cpp’]// Example.h
class Example
{
bool ThisNeedsTesting();
};

// in TestExample.cpp
#include “Example.h”
class TestExample : public Example
{
public:
bool TestThisNeedsTesting() { return ThisNeedsTesting(); }
};

TEST( TestThisNeedsTesting )
{
TestExample tester;
CHECK( tester.TestThisNeedsTesting, true );
}[/sourcecode]
Others get refactored out the classes they reside in and get put into their own functor classes – the current project has validation that is needed in several subclasses. These were first on my list to be refactored – they became functors and as a bonus made it easier to test – just a call to their public () operator. Others were functions that performed several duties. These too were split into separate functions and then split into functors as they weren’t directly related to the class they were in – they just played a supporting role.

Then I started on the larger objects. These became strategies. These strategies each implemented states via enums. These are massive classes and are a testing and maintenance nightmare – and one of these is what needed changing. According to Gamma, et al, states have a main state with empty functions. Specific states are derived from these states like so:
[sourcecode language=’cpp’]// I’ve left out the public declarations to save space
class State
{
virtual void StateOne() { };
virtual void StateTwo() { };
};

class StateBored : public State
{
virtual void StateOne() { /* do stuff */ }
};

class StateHappy : public State
{
virtual void StateTwo() { /* do happy stuff */ }
};[/sourcecode]
This really aids maintenance, extending and unit-testing as well, but it is screaming out to be functors with just the () operator being overridden in each. Like this:
[sourcecode language=’cpp’]// I’ve left out the public declarations to save space
class State
{
virtual void operator() () { };
};

class StateBored : public State
{
virtual void operator() () { /* do boring stuff */ }
};

class StateHappy : public State
{
virtual void operator() () { /* do happy stuff */ }
};[/sourcecode]
I am also sure that I will be finding more functors as I continue. Which really reduces most coding to functions – like traditional C programming. Does anyone else find them reducing nearly everything to functors?