I have a class System, which uses a bunch of other classes, to achieve some complex signal processing.
In debugging System, one needs to observe the output signal for patterns. This is not achievable by a debugger, because of the large number of samples going through.
However, if certain parts of System can be isolated and hooked to the environment, instead of System, this will allow for simpler transformations to be performed on the signal. Thus, it becomes easier to see if those individual parts are working.
This is in addition to tests to each class, that comprises System. Once integrated, the otherwise working components may exhibit bugs. Furthermore, testing 2 or 3 of those chained together is another approach to understanding why System is not performing correctly.
Consequently, methods were introduced in System to hook various inters from/to the environment. Those methods are not needed to a final user of the class, but also cannot be removed.
How can these methods be arranged, named, and mixed-in so that the interface is clear to an end user of the class? Also, while still providing the debugging behavior hacks?
10
My first reaction is that you should examine the possibility to use e.g. event tracing or logging in order to observe the system’s behavior instead of having explicit methods in your class. Existing frameworks often gives you the possibility to modify levels of output dynamically, i.e. at run time, with overhead that is acceptable for most environments.
That being said, if this is really the way you want to go, maybe something like this would be a bit cleaner (pseudo code, not C++):
interface IDebugInfo
{
int SomeDebugCounter();
}
interface IDebugInfoProvider
{
IDebugInfo GetDebugInfo();
}
class System
: IDebugInfoProvider
{
class SystemDebugInfo : IDebugInfo
{}
IDebugInfo GetDebugInfo()
{
return new SystemDebugInfo(...);
}
}
You might read about assert, which is relevant only if NDEBUG is not preprocessor defined.
So this suggests to wrap your debug-specific code with
#ifndef NDEBUG
//// debug specific code
#endif
and you could compile your production binary with -DNDEBUG …
My preference is simply to mention e.g. dbg in every name (of type, of function or method, of variable) related to debugging…
1