Exposing java service as static method or seam dependency

Question

Our legacy application provide a static method public static boolean persist(Data data) for service/class callers for data persistence.

I do see unit testing issue for callers. Is this also an example for tight coupling? - As far I understand, changes can be made inside static method without any changes required for callers so this should not be an tight coupling issue.

Are they additional disadvantages in using this approach compared to dependency injection approach to expose services?

P.S. This service will be called from multiple threads simultaneously. Service will perform database lookup, add additional data for persistence, call business logic etc. Service in itself has no state.

I also read following related article on dependency injection vs static for function: For function with no dependencies we can use static invocation. But again here this is a service and not a plain function call.

Please add comments if this is irrelevant per community standards and guide where such questions should be posted and where to learn about best practices for exposing java classes/services.

Answer 1

That's an interesting question!

Since you've encapsulated the logic in a (static) method, you've removed the duplication between the callers. So indeed, changes can be made to the method without having to change any caller.

Are they additional disadvantages in using this approach compared to dependency injection approach to expose services?

Yes, there is one main difference: the direction of the dependency.

Today, callers depend on the Service static method. You said that this method will interact with the DB. Therefore, callers depend on the DB, through the Service.

That problem will raise if you try to test the callers. You'll have to deal with the DB and that can be tricky. You'll end up trying to mock excessively references to the DB (or the Service). Since the reference is shared, that will make your tests coupled and harder to maintain.

Tests are an indicator of how easy it is to consume your code. If you're struggling writing the tests, you can probably improve the design.

By injecting the Service as a parameter, you invert the dependency. Basically, you make the callers depend on anything that provides the same Interface. So it's easy to provide a simple implementation in the tests that doesn't depend on the DB or anything like that.

Finally, as a rule of thumb, make as many dependencies explicit as possible. I recommend you to read this guide on Unit Testing Dependencies. It will give you concrete examples on the different scenario you can find out there!

Is this also an example for tight coupling?

The static method in itself, not necessarily. The static method depending on the Database means that you have a shared, mutable dependency. So you do have coupling.

Again, the best way to feel if that's a problem is to listen to your tests. If tests are easy to write and change, then it's a good sign that your code is re-usable. If they're not, you might want to improve your design.

I hope that helps. Happy to answer if you have further questions!