Question

This question is about testable software design based on mostly value objects and services.

Here’s an example of an API of a simple service that can save data to files.

saveToFile(data, fileName)
saveToUniqueFile(data, fileNameGenerator)

fileNameGenerator is a service that generates random file names. It is used to find a unique file name to save data to. In this example fileNameGenerator is injected as a method parameter.

One of the alternatives is constructor injection which would simplify the API:

saveToFile(data, fileName)
saveToUniqueFile(data)

Saving to a unique file certainly won’t be used every time, so it would seem that a mandatory constructor parameter should not be required. On the other hand, services usually communicate via data and here we have a service and it does clutter the API a bit.

Are there any potential problems/inconveniences of passing services around as method parameters? Should constructor injection still be preferred in such situations?

Answer 1

Passing services around as parameters is quite problematic, because you never know when you need them. Methods and their parameters constitute your API, whereas the constructor doesn’t. Using the constructor to inject services gives you a much larger degree of freedom because it allows you to decouple dependencies from the API expressed by the methods.

Otherwise you’d have to pass the method argument around to all methods in your API on the off chance that one or two of them might need it.

Even when a service is only used once in a while, it’s rarely an issue to use inject them via constructors.