Is Func appropriate to use as a ctor arg when applying Dependency Injection?

Question

Example:

public class BusinessTransactionFactory  where T : IBusinessTransaction
{
    readonly Func _createTransactio         


        

Answer 1

Mechanics

On the mechanical level, it's perfectly fine to used delegates, since a delegate is basically an anonymous Role Interface. In other words, whether you inject a delegate or interface or abstract base class doesn't really matter.

Concepts

On the conceptual level it's important to keep in mind the purpose of Dependency Injection. You may be using DI for different reasons than me, but IMO the purpose of DI is to improve the maintainability of a code base.

Whether or not this goal is accomplished by injecting delegates instead of interfaces is doubtful.

Delegates as dependencies

The first concern is about how well a delegate communicates intent. Sometimes an interface name communicates intent in itself, whereas a standard delegate type hardly does.

As an example, the type alone doesn't communicate much intent here:

public BusinessTransactionFactory(Func<Type, IBusinessTransaction> createTranscation)

Luckily, the createTranscation name still implies the role played by the delegate, but just consider (for argument's sake) how readable that constructor would have been if the author had been less careful:

public BusinessTransactionFactory(Func<Type, IBusinessTransaction> func)

In other words, using delegates shifts the focus from the name of the type to the name of argument. That's not necessarily a problem - I'm just pointing out that you need to be aware of this shift.

Discoverability versus Composability

Another concern is about discoverability versus composability when it comes to the types implementing the dependencies. As an examples, both of these implement public Func<Type, IBusinessTransaction>:

t => new MyBusinessTransaction()

and

public class MyBusinessTransactionFactory
{
    public IBusinessTransaction Create(Type t)
    {
        return new MyBusinessTransaction();
    }
}

However, in the case of a class, it's almost incidental that the concrete non-virtual Create method matches the desired delegate. It's very composable, but not very discoverable.

On the other hand, when we use interfaces, classes become part of is-a relationships when they implement interfaces, so it generally becomes easier to find all implementers and group and compose them accordingly.

Note that this is not only the case for programmers reading code, but also for DI Containers. Thus, it's easier to implement Convention over Configuration when you use interfaces.

1:1 interfaces versus the RAP

Some people have noticed that when attempting to use DI they end up with a lot of 1:1 interfaces (e.g. IFoo and a corresponding Foo class). In these cases, the interface (IFoo) seems redundant and it seems tempting to just get rid of the interface and use a delegate instead.

However, many 1:1 interfaces are really a symptom of a violation of the Reused Abstractions Principle. When you refactor a code base to reuse the same abstraction in multiple places, it makes sense to explicitly model the role of that abstraction as an interface (or abstract base class).

Conclusion

Interfaces are more than mere mechanics. They explicitly model roles in an application code base. Central roles should be represented by interfaces, whereas one-off factories and their ilk can be consumed and implemented as delegates.

Answer 2

I think the real question here is whether the dependency type should be considered a contract.

In the case of a Func delegate, you are declaring a dependency on a certain method structure, but nothing more. You cannot deduce the range of accepted input values (pre-conditions), constraints on the expected output (post-conditions), or what they mean exactly by looking at this structure. For example, is null an acceptable return value? And if it is, then how should it be interpreted?

In the case of an interface, you have a contract agreed upon by both parties: the consumer explicitly declares that it needs a particular interface, and the implementer explicitly declares to provide it. This goes beyond structure: the documentation of the interface will talk about the pre-conditions, post-conditions and semantics.

Answer 3

IF you inject Func I thin the code will be lazy, so in some case if you class depends from lots of other dependencies maybe is beter to inject Funct in that case. Im I right.

Sorry for my bad english

Answer 4

In the past, I have used both the pattern you mention (a delegate) and a single method interface. Currently, I tend to prefer the use of a single method interface.

The code required to mock the dependency is easier to read when using an interface and you will also have the ability to take advantage of automatically typed factories, as @devdigital mentions.

Another thing to consider is that you won't have the overhead of a delegate invocation when using an interface, which could be a valid consideration in very high performance applications.

Answer 5

I personally don't like to see Func<T> arguments as dependencies in my classes, because I think it makes the code less readable, but I know many developers don't agree with me. Some containers, such as Autofac, even allows you to resolve Func<T> delegates (by returning a () => container.Resolve<T>()).

There are however, two cases where I don't mind to inject Func<T> delegates:

1. When the class that takes the Func<T> constructor argument is located in the Composition Root, because in that case it's part of the container's configuration and I don't consider that part of the design of the application.
2. When that Func<T> is injected in a single type in the application. When more services start depending on that same Func<T>, it would be better for readability to create a special I[SomeType]Factory interface and inject that.

Answer 6

Yes, that is perfectly acceptable, although if you are using a container, more and more of them now support auto typed factories which would be preferable.

• Castle Windsor - Typed Factory Facility
• Ninject - Factory Extension