If I may be allowed to offer some general, instead of Ninject-specific, guidance on this, I would suggest that you reconsider your design slightly. The current constructor is vague because it offers no guidance about which implementation of IInterface that goes where - I realize that this is just a mock-up of your real API, and while the real API may offer more help to the human developer in the form of aptly named parameters, a machine like a DI Container cannot infer correct usage.
Many DI Containers offer some way to address such vagueness, for example by providing attributes you can use to associate names (metadata) with each dependency. AFAIR, Ninject has Inject
attributes...
However, consider a couple of alternatives:
The first alternative is to encapsulate the two similar interface instances in an Parameter Object, like this:
public interface IParameterObject
{
IInterface ObjectOne { get; }
IInterface ObjectTwo { get; }
}
You can now change the constructor to take an instance of IParameterObject instead of the two interface instances themselves.
public Something(IParameterObject po)
{
this.concreteObjectOne = po.ObjectOne;
this.concreteObjectTwo = po.ObjectTwo;
}
This means that you can push configuration of IParameterObject to the Composition Root.
Another alternative to ponder is whether it makes sense to consider the case with two instances as just a special case of a more general design that takes any number of instances. This may not always be the case, but if it is, you can change the constructor to this:
public Something(IEnumerable<IInterface> objects)
I would personally prefer any of the above suggestions over anything that uses specific Ninject features, because it forces me to make the API more explicit in general, and thus more readable and maintainable.