Using Func instead of interfaces for IoC

Question

Context: I am using C#

I designed a class, and in order to isolate it, and make unit testing easier, I am passing in all its dependencies; it does no object instantiation internally. However, instead of referencing interfaces to get the data it needs, I have it referencing general purpose Funcs returning the data/behavior it requires. When I inject its dependencies, I can just do so with lambda expressions.

To me, this seems like a better approach because I do not have to do any tedious mocking during unit testing. Also, if the surrounding implementation has fundamental changes, I will only need change the factory class; no changes in the class containing the logic will be needed.

However, I have never seen IoC done this way before, which makes me think there are some potential pitfalls I may be missing. The only one I can think of is minor incompatibility with earlier version of C# which don't define Func, and this is not an issue in my case.

Are there any problems with using generic delegates/higher order functions such as Func for IoC, as opposed to more specific interfaces?

Answer 1

If an interface does contain only one function, not more, and there is no compelling reason to introduce two names (the interface name and the function name inside the interface), using a Func instead can avoid unnecessary boilerplate code and is in most cases preferable - just like when you start to design a DTO and recognize it needs only one member attribute.

I guess lots of people are more used to using interfaces, because at the time when dependency injection and IoC were getting popular, there was no real equivalent to the Func class in Java or C++ (I am not even sure if Func was available at that time in C#). So lots of tutorials, examples or textbooks still prefer the interface form, even if using Func would be more elegant.

You might look into my former answer about the interface segregation principle and Ralf Westphal's Flow Design approach. This paradigma implements DI with Func parameters exclusively, for exactly the same reason you mentioned already by yourself (and some more). So as you see, your idea is not a really new one, quite the opposite.

And yes, I used this approach by myself, for production code, for programs which needed to process data in form of a pipeline with several intermediate steps, including unit tests for each of the steps. So from that I can give you first hand experience that it can work very well.

Answer 2

One of the main advantages I find with IoC is that it will allow me to name all my dependencies via naming their interface, and the container will know which one to supply to the constructor by matching the type names. This is convenient and it allows much more descriptive names of dependencies than Func<string, string>.

I also often find that even with a single, simple dependency, sometimes it needs to have more than one function - an interface allows you to group these functions together in a way that is self-documenting, vs having multiple parameters that all read like Func<string, string>, Func<string, int>.

There are definitely times when it's useful to simply have a delegate that is passed in as a dependency. It's a judgement call as to when you use a delegate vs having an interface with very few members. Unless it's really clear what the purpose of the argument is, I will usually err on the side of producing self-documenting code; ie. writing an interface.

Answer 3

Are there any problems with using generic delegates/higher order functions such as Func for IoC, as opposed to more specific interfaces?

Not really. A Func is its own sort of interface (in the English meaning, not C# meaning). "This parameter is something that supplies X when asked." The Func even has the benefit of lazily supplying the information only as needed. I do this a bit and recommend it in moderation.

As for downsides:

• IoC containers often do some magic to wire up dependencies in a cascaded sort of way, and probably won't play nice when some things are T and some things are Func<T>.
• Funcs have some indirection, so can be a little harder to reason about and debug.
• Funcs delay instantiation, meaning runtime errors may show up at weird times or not at all during testing. It can also increase the chances of order of operations issues and depending on your use, deadlocks in initialization ordering.
• What you pass into the Func is likely to be a closure, with the slight overhead and complications those entail.
• Calling a Func is a bit slower than accessing the object directly. (Not enough that you'll notice in any non-trivial program, but it's there)

Answer 4

Let's take a simple example-- perhaps you are injecting a means of logging.

Injecting a class

class Worker: IWorker
{
    ILogger _logger;

    Worker(ILogger logger)
    {
        _logger = logger;
    }
    void SomeMethod()
    {
        _logger.Debug("This is a debug log statement.");
    }
}        

I think that is pretty clear what is going on. What's more, if you are using an IoC container, you don't even need to inject anything explicitly, you just add to your composition root:

container.RegisterType<ILogger, ConcreteLogger>();
container.RegisterType<IWorker, Worker>();
....
var worker = container.Resolve<IWorker>();

When debugging Worker, a developer just needs to consult the composition root to determine what concrete class is being used.

If a developer needs more complicated logic, he has the whole interface to work with:

    void SomeMethod()
    { 
       if (_logger.IsDebugEnabled) {
           _logger.Debug("This is a debug log statement.");
       }
    }

Injecting a method

class Worker
{
    Action<string> _methodThatLogs;

    Worker(Action<string> methodThatLogs)
    {
        _methodThatLogs = methodThatLogs;
    }
    void SomeMethod()
    {
        _methodThatLogs("This is a logging statement");
    }
}        

First, notice that the constructor parameter has a longer name now, methodThatLogs. This is necessary because you can't tell what an Action<string> is supposed to do. With the interface, it was completely clear, but here we have to resort to relying on parameter naming. This seems inherently less reliable and harder to enforce during a build.

Now, how do we inject this method? Well, the IoC container won't do it for you. So you are left injecting it explicitly when you instantiate Worker. This raises a couple problems:

1. It is more work to instantiate a Worker
2. Developers attempting to debug Worker will find it is more difficult to figure out what concrete instance gets called. They can't just consult the composition root; they will have to trace through code.

How about if we need more complicated logic? Your technique only exposes one method. Now I suppose you could bake the complicated stuff into the lambda:

var worker = new Worker((s) => { if (log.IsDebugEnabled) log.Debug(s) } );

but when you are writing your unit tests, how do you test that lambda expression? It's anonymous, so your unit test framework can't instantiate it directly. Maybe you can figure out some clever way to do it, but it'll probably be a bigger PITA than using an interface.

Summary of the differences:

1. Injecting only a method makes it harder to infer the purpose, whereas an interface clearly communicates the purpose.
2. Injecting only a method exposes less functionality to the class receiving the injection. Even if you don't need it today, you may need it tomorrow.
3. You cannot automatically inject only a method using an IoC container.
4. You cannot tell from the composition root which concrete class is at work in a particular instance.
5. It is a problem to unit test the lambda expression itself.

If you are OK with all of the above, then it's OK to inject just the method. Otherwise I'd suggest you stick with tradition and inject an interface.

Answer 5

Consider the following code I wrote long ago:

public interface IPhysicalPathMapper
{
    /// <summary>
    /// Gets the physical path represented by the relative URL.
    /// </summary>
    /// <param name="relativeURL"></param>
    /// <returns></returns>
    String GetPhysicalPath(String relativeURL);
}

public class EmailBuilder : IEmailBuilder
{
    public IPhysicalPathMapper PhysicalPathMapper { get; set; }
    public ITextFileLoader TextFileLoader { get; set; }
    public IEmailTemplateParser EmailTemplateParser { get; set; }
    public IEmaiBodyRenderer EmailBodyRenderer { get; set; }

    public String FromAddress { get; set; }

    public MailMessage BuildMailMessage(String templateRelativeURL, Object model, IEnumerable<String> toAddresses)
    {
        String templateText = this.TextFileLoader.LoadTextFromFile(this.PhysicalPathMapper.GetPhysicalPath(templateRelativeURL));

        EmailTemplate template = this.EmailTemplateParser.Parse(templateText);

        MailMessage email = new MailMessage()
        {
            From = new MailAddress(this.FromAddress),
            Subject = template.Subject,
            IsBodyHtml = true,
            Body = this.EmailBodyRenderer.RenderBodyToHtml(template.BodyTemplate, model)
        };

        foreach (MailAddress recipient in toAddresses.Select<String, MailAddress>(toAddress => new MailAddress(toAddress)))
        {
            email.To.Add(recipient);
        }

        return email;
    }
}

It takes a relative location to a template file, loads it into memory, renders the message body, and assembles the e-mail object.

You might look at IPhysicalPathMapper and think, "There's only one function. That could be a Func." But actually, the problem here is that IPhysicalPathMapper shouldn't even exist. A much better solution is to just parameterize the path:

public class EmailBuilder : IEmailBuilder
{
    public ITextFileLoader TextFileLoader { get; set; }
    public IEmailTemplateParser EmailTemplateParser { get; set; }
    public IEmaiBodyRenderer EmailBodyRenderer { get; set; }

    public String FromAddress { get; set; }

    public MailMessage BuildMailMessage(String templatePath, Object model, IEnumerable<String> toAddresses)
    {
        String templateText = this.TextFileLoader.LoadTextFromFile(templatePath);

        EmailTemplate template = this.EmailTemplateParser.Parse(templateText);

        MailMessage email = new MailMessage()
        {
            From = new MailAddress(this.FromAddress),
            Subject = template.Subject,
            IsBodyHtml = true,
            Body = this.EmailBodyRenderer.RenderBodyToHtml(template.BodyTemplate, model)
        };

        foreach (MailAddress recipient in toAddresses.Select<String, MailAddress>(toAddress => new MailAddress(toAddress)))
        {
            email.To.Add(recipient);
        }

        return email;
    }
}

This raises a whole host of other questions to improve this code. E.g., maybe it should just accept an EmailTemplate, and then maybe it should accept a pre-rendered template, and then maybe it should just be in-lined.

This is why I don't like inversion of control as a pervasive pattern. It's generally held up as this god-like solution to composing all your code. But in reality, if you use it pervasively (as opposed to sparingly), it makes your code much worse by encouraging you to introduce a lot of unnecessary interfaces that are used completely backwards. (Backwards in the sense that the caller should really be responsible for evaluating those dependencies and passing the result in rather than the class itself invoking the call.)

Interfaces should be used sparingly, and inversion of control and dependency injection should also be used sparingly. If you have larges amounts of them, your code becomes much more difficult to decipher.