CODEWITHSUNDEEP
c#interface
Tesserex
Tesserex

Reputation: 17314

Proper way for form events to reach into application

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.

Upvotes: 1

Views: 83

Answers (3)

Aaronaught
Aaronaught

Reputation: 122624

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.

Upvotes: 1

FMM
FMM

Reputation: 4329

I'd highly recommend reading Ninject's walkthrough of dependency injection (be sure to read through the entire tutorial). I know this may seem like a strange recommendation given your question; however, I think this will save you a lot of time in the long run and keep your code cleaner.

Your debug code seems to depend on SpecificState; therefore, I would expect that your debug menu items would ask the DI container for their dependencies, or a provider that can return the dependency or null. If you're already working on refactoring to include DI, then providing your debug menu items with the proper internal bits of your application as dependencies (via the DI container) seems to be an appropriate way to achieve that without breaking solid design principles. So, for instance:

public sealed class DebugMenuItem : ToolStripMenuItem
{
    private SpecificStateProvider _prov;

    public DebugMenuItem(SpecificStateProvider prov) : base("Debug Item")
    {
       _prov = prov;
    }
    // other stuff here

    protected override void OnClick(EventArgs e)
    {
        base.OnClick(e);


        SpecificState state = _prov.GetState();
        if(state != null)
           state.MessWithStuff();
    }
}

This assumes that an instance of SpecificState isn't always available, and needs to be accessed through a provider that may return null. By the way, this technique does have the added benefit of fewer event handlers in your form.

As an aside, I'd recommend against violating design principles for the sake of debugging, and have your debug "muck with stuff" methods interact with your internal classes the same way any other piece of code must - by its interface "contract". You'll save yourself a headache =)

Upvotes: 1

Enigmativity
Enigmativity

Reputation: 117047

I'd be inclined to look at dependency injection and decorators for relatively large apps, as FMM has suggested, but for smaller apps you could make a relatively easy extension to your existing code.

I assume that you push an instance of Logic down to the parts of your app somehow - either though static classes or fields or by passing into the constructor.

I would then extend Logic with this interface:

public interface ILogicDebugger
{
    IDisposable PublishDebugger<T>(T debugger);
    T GetFirstOrDefaultDebugger<T>();
    IEnumerable<T> GetAllDebuggers<T>();
    void CallDebuggers<T>(Action<T> call);
}

Then deep down inside your code some class that you want to debug would call this code:

var subscription =
    logic.PublishDebugger(new MessWithStuffHere(/* with params */));

Now in your top-level code you can call something like this:

var debugger = logic.GetFirstOrDefaultDebugger<MessWithStuffHere>();
if (debugger != null)
{
    debugger.Execute();
}

A shorter way to call methods on your debug class would be to use CallDebuggers like this:

logic.CallDebuggers<MessWithStuffHere>(x => x.Execute());

Back, deep down in your code, when your class that you're debugging is about to go out of scope, you would call this code to remove its debugger:

subscription.Dispose();

Does that work for you?

Upvotes: 0

Related Questions