I'm confused about interface abstractions when using IoC

Question

I\'ve recently been trying to learn IoC, and have a couple questions based on the following code:

public class WarriorModule : NinjectModule 
{
    public          


        

Answer 1

I recently addressed this topic from a more general viewpoint. The bottom line is that there's a tendency for loosely coupled code to produce an overabundance of 1:1 interfaces. This is contrary to the Reused Abstractions Principle.

However, this is more of an application design issue than it's an issue regarding particular DI Containers. While I don't know Ninject, all other containers I've ever worked with (Castle Windsor, StructureMap, Spring.NET, Autofac, Unity, and even MEF) can map multiple implementations to the same interface. How they do this differ slightly, but I cover all of them in part IV of my book - unfortunately, Ninject is not covered in the book.

Answer 2

A good IoC container should not change the way interfaces are used:

1. An interface should be designed for the component that is using it as dependency and not the class that is implementing it. (interface segregation principle)
2. A class can implement several interfaces. But this should only be done if those interfaces are for the same kind of service so that the class does exactly one thing. If the interfaces are for two different things they should be implemented by two different classes. (single responsibility principle)
3. Several classes can implement the same interface if you need multiple strategies for this type of service.

Ninject allows using interfaces this way using two different concepts:

1. Conditional bindings: If several classes implement the same interface you have to specify which implementation is used in which case. This is done using conditions:

   Bind<IWeapon>().To<Sword>().When(ctx => TodayIsSunday());

   Bind<IWeapon>().To<Dagger>().When(ctx => !TodayIsSunday());

2. Multiple Interfaces: See my blogpost http://www.planetgeek.ch/2010/12/08/ninject-extension-contextpreservation-explained/