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

I can't say that I entirely see the point. After all, it would likely be a few lines of code to wire up the system in a main method and you would then not have the dependency on Spring.

And yes, I agree that not injecting interfaces is a bit pointless. I tend not to do a huge amount of Unit testing but, even so, I would lose any flexibility in changing implementations later on (or having different implementations of classes in different deployments - e.g. integration testing).

Answer 3

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.

Answer 4

I'm sorry, but I can't tell if this is an abuse of Spring based on the two lines of code that you posted and I doubt that anyone else can, either.

If you're complaining about the fact that the static type of that object is not an interface you might have a point. But even that's hard to tell from that single line of code. Is that really a service or repository class without an interface? If so, I agree. If not, I'd need to know more.

If your team frowns on testing, that's too bad. I would have thought that one of the reasons for Spring would be to facilitate testing.

You might have a point, but I can't be sure from your original question. Maybe you can edit in more detail.

If this is an example of how you communicate with your teammates, perhaps they'd be justified if they said that you didn't explain yourself very well. Make sure that you aren't just out for self-aggrandization here.