Question

I have some debugging functions that I would like to refactor, but seeing as they are debugging functions, it seems like they would be less likely to follow proper design. They pretty much reach into the depths of the app to mess with things.

The main form of my app has a menu containing the debug functions, and I catch the events in the form code. Currently, the methods ask for a particular object in the application, if it’s not null, and then mess with it. I’m trying to refactor so that I can remove the reference to this object everywhere, and use an interface for it instead (the interface is shared by many other objects which have no relation to the debugging features.)

As a simplified example, imagine I have this logic code:

public class Logic
{
    public SpecificState SpecificState { get; private set; }
    public IGenericState GenericState { get; private set; }
}

And this form code:

private void DebugMethod_Click(object sender, EventArgs e)
{
    if (myLogic.SpecificState != null)
    {
        myLogic.SpecificState.MessWithStuff();
    }
}

So I’m trying to get rid of the SpecificState reference. It’s been eradicated from everywhere else in the app, but I can’t think of how to rewrite the debug functions. Should they move their implementation into the Logic class? If so, what then? It would be a complete waste to put the many MessWithStuff methods into IGenericState as the other classes would all have empty implementations.

edit

Over the course of the application’s life, many IGenericState instances come and go. It’s a DFA / strategy pattern kind of thing. But only one implementation has debug functionality.

Aside: Is there another term for “debug” in this context, referring to test-only features? “Debug” usually just refers to the process of fixing things, so it’s hard to search for this stuff.

Answer 1

Create a separate interface to hold the debug functions, such as:

public interface IDebugState
{
    void ToggleDebugMode(bool enabled); // Or whatever your debug can do
}

You then have two choices, you can either inject IDebugState the same way you inject IGenericState, as in:

public class Logic
{
    public IGenericState GenericState { get; private set; }
    public IDebugState DebugState { get; private set; }
}

Or, if you’re looking for a quicker solution, you can simply do an interface test in your debug-sensitive methods:

private void DebugMethod_Click(object sender, EventArgs e)
{
    var debugState = myLogic.GenericState as IDebugState;
    if (debugState != null)
        debugState.ToggleDebugMode(true);
}

This conforms just fine with DI principles because you’re not actually creating any dependency here, just testing to see if you already have one – and you’re still relying on abstractions over concretions.

Internally, of course, you still have your SpecificState implementing both IGenericState and IDebugState, so there’s only ever one instance – but that’s up to your IoC container, none of your dependent classes need know about it.