Having overload methods that use IoC container.

Question

I am writing a API over the top of a COM object and you have to pass around the COM object into pretty much every type and static method that I write so that I can test each part of my API.

Now my question is do I have an overloaded method for the one that takes the COM object but pass the IoC resolved one instead to the other one instead, so that the users of the API don't have to worry about passing in the COM object or should I remove the overloaded method and just resolve it with out the option to pass it in.

Bit hard to explain so here is an example;

Constuctor Example;

FooType(IComObject obj,string table) {}
FooType(string table) : this(Ioc.Resolve<IComObject>(), table) {}

or just

FooType(string table) : this(Ioc.Resolve<IComObject>(), table) {}

Static method example;

public static SomeType Create(IComObject obj,string table) 
{ // Do some work with obj}

public static SomeType Create(string table) 
{ 
   return MyClass.Create(Ioc.Resolve<IComObject>(),table);
}

or just

public static SomeType Create(string table) 
{ 
   IComObject obj = Ioc.Resolve<IComObject>();
   return MyClass.Create(Ioc.Resolve<IComObject>(),table);
}

My biggest worry with the overloading is that it's going to create a lot of methods that just froward calls. What other options do I have here or is this correct way of tackling this?

P.S I really don't want to burden the user with having to pass a instance of IComObject all around their application.

Answer 1

From my point of view, unless you have a compelling reason to allow the overload, having both (overload and resolution) will unnecessarily complicate your API and lead too potential gotchas for your users.

I think you have answered your own question when you said "P.S I really don't want to burden the user".

Answer 2

From one side, you easily can drop methods like

public static SomeType Create(IComObject obj,string table)

at all because you can register a mock object of IComObject type during tests and easily run these tests.
But on the other side, this will break SoC and Open/Closed principles. Your methods know too much in this case (that there are some DI and so on). From design (architecture) side it's more better to use methods like "Create(IComObject obj,string table)" only and refactor the code to minify usage of Ioc.Resolve() and use it only in initializers, fabrics or something like this. And it's very hard to explain how to refactor this without seeing all the code.
So the answer is - it depends.
EDIT:
There is a very good post about this case. Check it, it contains the answer =)

Answer 3

One of the principles of Dependency Injection is that dependencies of a class should be made explicit to the outside world. When a class resolves a dependency itself (as in your second example) it goes against that principle, and is headed back down the road of using singleton services - though admittedly you are somewhat better off because you do have the IoC container as an "escape hatch" for mocking the service objects.

Obviously having a whole load of parameters in the constructors of all your objects is rather burdensome, but that's where the IoC Container steps in. If it supports auto-wiring, and you're using it as it was designed, you usually find yourself having to resolve very few instances yourself: you pull the first object out, and it comes ready-configured with all its dependencies - and they're ready configured with all their dependencies, and so on. For this reason, Joshua Flanagan makes the argument that IoC Containers really ought to be called IoC Composers.

If you want to avoid burdening the users of your API, how about having a focal object that wraps up your IoC container and pulls configured instances out of it for consumption by calling code?

Answer 4

If the users care about the IComObject instance then creating an overload is the way to go.

If the IComObject is an implementation detail for your users, and you're the only one who cares about testing, then you should just expose a simple Factory method that your classes use to instantiate/access the IComObject internally.

Generally speaking, if the user is going to care about the IComObject then it won't be a burden if you create an overload. Personally as a developer I always want as many options as I can get.