Spring as a glorified factory; is this acceptable?

Question

I just inherited a Java application and upon inspection of the code, I'm seeing what IMHO is a bastardization of the Spring framework. You see, the Java team seems to have an aversion to interfaces, so we end up with things like this:

@Autowired
private SomeConcreteFinalClass _myField;

There's no Spring configuration, no bean defined, no chance that I can test the containing object in isolation. This is essentially an annotation-based factory with the overhead of Spring.

Am I out-of-line, or is this like using an elephant gun to kill flies? I just have to have a reality check since everyone else on the team thinks this is perfectly acceptable.

Edit In many cases these annotated factories appear in complex processing classes that would benefit immensely from isolated testing. The team also frowns upon testing though.

There's no mystery here, I hope. If I have a concrete class, that's not behind an interface, and there's no corresponding Spring bean to "setup" the object, then it's inarguably a glorified factory that can be implemented with 10 lines of code.

Spring is not used in any other way in the system; this is it.

My goals right now:

• Institute a testing policy
• Educate the team on the virtues of component isolation
• Move these Autowired fields behind interfaces

I guess the final question is: is there any benefit to keeping these fields Autowired if we're not testing or in any other way utilizing the framework. I'd just as well new the object if the dependency is immutable.

Answer 1

I would agree with you that this is an abuse of what Spring can do (as opposed to what Spring SHOULD do). Is the person who designed the application this way around? It would be interesting to hear their justification for building an application this way.

Answer 2

It's certainly limiting what is possible, but it's not a total waste of time either.

Since the type in question is final, it can't be mocked-up easily for isolated testing.

However, instances of that type may still be highly configurable through their properties. Using Spring to inject an instance that is properly configured at runtime simplifies the containing class immensely. The class can focus on its responsibilities, relying on Spring to provide it with the collaborators that it needs.

Interfaces are over used; this may be a response to that. I think that starting with final, concrete classes for many types, then using readily-available refactoring tools to extract interfaces later, when a specific need is identified, is a defensible position in many contexts.