I know you’ve said the injector code is untestable, but I do have tests where the object under test is provided to me by the factory. In this case, I sometimes extend the factory with an anonymous class from the test and override inject methods to use as test doubles.

PS. If you haven’t seen the New Zealand move Black Sheep, you should watch it, it’s a classic.

It’s only safe to do that if the injector is calling the static method and giving the result to the application code. Specifically, you can’t do it if the class containing the static method were ever going to be injected into the application code itself. And you also can’t ever do it if you want interoperability with non-DI code, which is what usually dissuades me.

Let me know if my thinking on this seems unclear, and I could put together a code sample.

I didn’t really understand that. I consider static an evil reserved for main(). Most of our business logic classes consist of a constructor (which just stores values in member variables) and a single method that does something. Our entity/value classes have a constructor and getters. Sometimes they have setters as well. The factory classes contain many protected inject*() methods. Nothing is static except where our code is invoked from externally.

What type of class are you talking about that you would make static? Factory, entity or service?

My code also ends up containing a lot of one-method classes. Sometimes I’m tempted to just make them static methods, so I don’t have to write boilerplate code for all the class’s fields. The only reason I don’t is so that the application will still be marginally testable if someone with a non-DI client tries to reuse my code. In a pure DI application, static methods can still be testable as long as they are only called from the glue code, not the business logic.

I commented previously on Misko’s blog. I wrote a non-trivial piece of code and I’m convinced the factory methods should not be static.

In the simple case, our top level code then looks like this:

Factory factory = new Factory( scope );
Processor processor = factory.getProcessor();
processor.process();

We are working in a hosted-service environment and different customers want different things. Therefore, this code actually becomes:

Factory factory = newFactoryForCustomer( customer, scope );
Processor processor = factory.getProcessor();
processor.process();

Where newFactoryForCustomer() returns different instances depending on the customer. These instances extend a base factory. When a customer wants something special, we override an inject*() method in their specific factory.

I also noticed that I ended up with alot of classes containing a constructor and a single method. Many of these ended up implementing Provider. I was comfortable with this because the coupling is very loose, and they are easy to replace with test doubles.

Cheers,
Will