Dependency Injection - Who owns the Interface?

Question

Assuming I want to use a dependency injection framework in an AOP approach, with the goal of producing code modules. What's the best practice for the ownership of the shared interfaces? By ownership I mean the body of code that needs to be referenced in order to use the interface.

My first guess is that in AOP you would define a class library of interfaces, namespaced by aspect. eg: company.aspect.logging.ILogger. Each module would then reference this library and avoid having any code involved in implementation of ILogger also define ILogger.

Best practices?

Answer 1

Defining a class library of interfaces is a good start. That gives you the ultimate in flexibility because you can vary all consumers and all implementers completely independently of each other.

The disadvantage of this approach is that if your interfaces themselves export other interfaces like this:

public interface IMyInterface
{
    IMyOtherInterface DoStuff();
}

you may need to write a lot of mapping code that can populate concrete classes from the interfaces (or you can ause AutoMapper).

If you only have one consumer but several impelementers, you can save yourself some of this mapping by defining the interfaces together with the consumer (never with the implementer), but you lose some of the flexibility. However, you can still vary the implementers independently of the consumer, but not the other way around.

Answer 2

It depends on the purpose of the interface:

If the purpose of the interface is to define a standard protocol between a set of alternative suppliers and a single consumer, the interface is owned by the consumer.

If the purpose of the interface is to define a standard protocol between a single supplier and a set of alternative consumers, the interface is owned by the supplier.

If the purpose of the interface is to define a standard protocol between a set of alternative suppliers and a set of alternative consumers, the interface stands on it's own.

Finally, if interfaces are being used as a general approach to reduce complexity, they are typically owned by the consumers and should be defined as narrowly as possible such that each interface supports the consumer's needs in specific requirements context.