使用DI的单一方法委托与接口

Question

I have a task doing some background work which I want to throttle. I want to inject the void Throttle(taskState) method. It can be as simple as Thread.Sleep(delay) for debugging purposes, but it can be more complex, doing some logging etc.

I'm choosing between a delegate and an interface with a single method, as a parameter to the constructor of the task-driving class. Which option to take?

IMO, when it comes to DI, the major advantage of interfaces over delegates is extensibility. New methods can be easily added. I can create interface I2: I1 { ... } , have the class implement I2 , and still inject an instance of it as I1 . The client code has an option to cast it to I2 , to see if the new features are supported.

However, if I need to inject just a single method, I think a delegate would make more sense, regardless of whether I need to maintain state or not. Delegates can maintain state too, eg:

static Action<TaskState> GetThrottle(int delay) 
{ 
    return (s) => Thread.Sleep(delay++);
} 

I'd explicitly type my delegate, rather than using Action<> or Func<> .

Currently, I plan to have a separate static class with various Throttle implementations like above.

I'm not using any DI frameworks for this projects.

Is this the right choice? Should I go with an interface instead?

If you think the answer would be mostly opinion-based, just vote to close this question, that'd help too.

Answer 1

The one advantage that passing an interface to the constructor would have is it makes the dependency resolution easier to declare in a DI framework. If a have a class like.

public class ClassA{
    public ClassA(IInterface interface){
    ...
    }
}

then using a DI framework like Unity I can easily register the type like so

 container.RegisterType<IInterface, ConcreteImplementation>();

Its a little harder to get right with delegates. you would probably have to do something like.

public class ClassA{
    public ClassA(Delegate delegateInstance){
    ...
    }
}

then to register the dependency its a bit tougher.

 container.RegisterType<ClassA>(
     new InjectionFactory(a => {
         return new ClassA(()=>{/*delegate code*/});
 }));

Answer 2

In one of his talks, wise man David Chappell had once said that if you are facing a design problem that has a couple of approaches to solve it, and you have to decide between a shortcut or a path that is bit difficult but provides extensibility, choose the later. Extensibility might come in handy if needed down the road. If you are driving a car at night, there is only so far you can see as your headlights reach. As you move forward, road becomes clearer and clearer. Though this may not apply to every possible scenario out there, this advice has helped me immensely.

In your case, if I wasn't sure that one delegate is all that I am ever going to need, I would make it extensible by using interfaces.

Answer 3

The ability to add extra methods to an interface is a double-edged sword. Several classes depend on an interface. One class needs some extra dependency, and someone decides to shove it into the existing interface (and its implementation.) They shouldn't, but they do. Now the dependency has an extra method that other classes don't need, so interface segregation is violated. Plus the class that depends on it is doing more, but it's harder to tell because its number of dependencies hasn't increased.

You can register delegates with DI containers. It's not pretty at first, but with a few extension methods it's okay. There may be cases where a static method is suitable, and registering a static method as the implementation of a delegate is really easy because there's no type to register or resolve, just the delegate itself.

Here's an example using Autofac:

Delegate:

public delegate Single DoMath(Single value1, Single value2);

Extension:

public static class AutofacBuilderExtensions 
{ 
    public static IRegistrationBuilder<TDelegate, SimpleActivatorData, SingleRegistrationStyle> RegisterDelegate<TDelegate, TSource>( 
        this ContainerBuilder builder,  
        Func<TSource, TDelegate> extractDelegate,  
        string sourceComponentName = null,  
        string registeredComponentName = null)  
        where TDelegate : class
    {
        var registrationFunction = new Func<IComponentContext, TDelegate>(context => 
        { 
            var c = context.Resolve<IComponentContext>(); 
            var source = sourceComponentName == null 
                ? c.Resolve<TSource>() 
                : c.ResolveNamed<TSource>(sourceComponentName); 
            return extractDelegate(source); 
        }); 

        return registeredComponentName == null ? 
            builder.Register(registrationFunction) : 
            builder.Register(registrationFunction) 
                .Named<TDelegate>(registeredComponentName); 
    } 
}

// register the type containing the method so it can be resolved,
// and then register the implementation of the delegate using the extension.
builder.RegisterType<AddsNumbers>();
builder.RegisterDelegate<DoMath, AddsNumbers>(addsNumbers => addsNumbers.DoMath);

Or if you're just registering a static implementation:

builder.Register<DoMath>(context => MyStaticMathClass.AddsNumbers);

More details, plus Windsor extensions