Func vs Interfaces for IoC – Using Func for Inversion of Control

Architecturedelegatesinterfacesinversion-of-control

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?

Best Answer

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.

Related Solutions

Object-oriented – When to use interfaces (unit testing, IoC?)

In general, if you make an interface which only has one implementor, you're just writing things twice and wasting your time. Interfaces alone do not provide loose coupling if they're tightly coupled to one implementation... That said, if you want to mock these things in unit tests, that's usually a great sign that you'll inevitably need more than one implementor in real code.

I would consider it a bit of a code smell if nearly all your classes have interfaces though. That means they're almost all working with one another in one way or another. I would suspect that the classes are doing too much (since there's no helper classes) or you've abstracted too much (oh, I want a provider interface for gravity since that might change!).

Dependency Injection – Abstract Factory Patterns in C#

It seems you're struggling trying to create objects that create objects... wouldn't you be better off just creating objects ?

Ninject allows you to do so in a very simple way :

// Ninject module
Bind<IRepository<SomeEntity>>().To<SomeEntityRepository>();

// injected class
public class SomeService
{
  public SomeService(IRepository<SomeEntity> repository)
  {
    // ...
  }
}

// get instance of injected class
var someService = kernel.Get<SomeService>();

I can't see the benefit of an abstract factory in addition to an IoC container when you're creating objects based on basic, compile-time-known constraints such as in your SomeViewFactory and SomeRepositoryFactory examples.

The dynamic nature of SomeFunctionalityFactory would be more debatable, but when you think of it, do you really need to instantiate an object with the built-in notion that it will never be able to be used by the current user ? Wouldn't it make more sense to have the object evaluate user authorization when the functionality is called ?

Best Answer

Related Solutions

Object-oriented – When to use interfaces (unit testing, IoC?)

Dependency Injection – Abstract Factory Patterns in C#

Related Topic