Extending a class for debugging: public API, hidden implementation or something else?

Question

I'm working on a fairly large project that involves 3D drawing, and I want to add some visualizers (for example, to see the bounding boxes of the objects) to make debugging easier. However, I'm having a problem in deciding how to go about this.

One option would be to create a public function to draw the visualizers, and call this function when I enable debugging from the UI. This would have the advantage of not modifying the existing functions, but extending the class with a new function. The disadvantage would be "creating dependencies", as one of my colleagues said, we would need to modify the base class, and all the deriving classes to add this function.

Another option would be to modify the existing drawing function so that it handles the drawing of the visualizers. This hides the implementation details, but also it seems to me it makes the code less modular.

Yet another option is extending the class, adding the visualizer in the drawing function, and swapping classes when debugging is enabled. Mixins would be of help, but C++ doesn't support that.

What would be the best approach to do this? I'm looking for a solution that is modular and respects the SOLID principles.

• Bart van Ingen Schenau: Are those visualizers only helpful when looking for the cause of defects, or could they also be helpful to regular users in performing some task? I could imagine that the bounding box you give as example could also be useful to regular users.
• Nini Michaels: Just for developers finding defects. A regular user should not see the bounding boxes nor the triangle count of the models.

Answer 1

If you want SOLID, I would go mainly with S(ingle Responsability) and D(ependency Injection):

For example, for the bounding boxes:

1. create a base abstract class with the, say, drawBox method.
2. create the "regular" implementation (for example, it does nothing) and the "debug" implementations.
3. your classes will use a regular implementation by default, but will allow the injection (through a constructor/method, or by a using a factory) of other instances.

Let's check

S: Each class does only one thing (your business class do not have a "debug mode" or a "production mode")

O: If you create a new subclass of the abstract class, you do not need to change your business classes to use it.

D: Well, dependency injection is the mechanism used.