Question

Example:

public class BusinessTransactionFactory<T>  where T : IBusinessTransaction
{
    readonly Func<Type, IBusinessTransaction> _createTransaction;

    public BusinessTransactionFactory(Func<Type, IBusinessTransaction> createTransaction)
    {
        _createTransaction = createTransaction;
    }

    public T Create()
    {
        return (T)_createTransaction(typeof(T));
    }
}

Container setup code utilising same:

public class DependencyRegistration : Registry
{
    public DependencyRegistration()
    {
        Scan(x =>
        {
            x.AssembliesFromApplicationBaseDirectory();
            x.WithDefaultConventions();
            x.AddAllTypesOf(typeof(Repository<>));
            x.ConnectImplementationsToTypesClosing(typeof(IRepository<>));
        });

        Scan(x =>
        {
            x.AssembliesFromApplicationBaseDirectory();
            x.AddAllTypesOf<IBusinessTransaction>();
            For(typeof(BusinessTransactionFactory<>)).Use(typeof(BusinessTransactionFactory<>));
            For<Func<Type, IBusinessTransaction>>().Use(type => (IBusinessTransaction)ObjectFactory.GetInstance(type));
        });


        For<ObjectContext>().Use(() => new ManagementEntities());
    }
}

What do you think?

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.