Should dynamic dependencies of service objects be avoided?

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

Services that have static dependencies are straightforward to instantiate or configure when using a DI container. However, in some cases, services require dependencies that are known at runtime only.

Say, imagine a simple FileSystemDataStore with some CRUD methods in it for managing files in a directory. This service will need a directory name as one of its constructor parameters. That name could be known at runtime only and will have to be provided by its collaborators.

This seems to be somewhat of a problem because you can't configure such service in a DI container because of its dynamic nature. You'll probably have to use a factory to create such services. However, this will result in a quirk in the unit tests of the service's clients. You will have to mock the factory to return a mock of the service. This adds additional complexity to unit tests. Mocks returning mocks is often considered a test smell.

What is your opinion about this problem? Is it even a开发者_开发技巧 problem in your experience? Should such services be instead refactored to be more "pure"?

As a general observation, when services depend on run-time values, an Abstract Factory is indeed the appropriate response.

However, as pointed out in the question, this does have an impact on the maintainability of the tests, so if you can redesign the API to avoid such situations, you should do that. It's not always possible, though.

You would like to inject the directory name, but it is not known during the construction phase. I see three options here.

1. Inject a Provider

Instead of saying "Here is the directory name you need" you are saying "Here is an object that can give you the directory name at run-time". The way to implement this is to declaring a constructor argument Provider<String> directoryNameProvider. The constructor stores a reference to this provider as a member variable. When called apon to do some real-work in the run phase, the class would contain code like this when the directory name is needed:

directoryName = directoryNameProvider.get();

In java, the interface you implement is [javax.inject.Provider<T>][1]. This has a single method: get() which returns type T. The use of the generic provider interface means you do not have a proliferation of intefaces.

When it comes to your unit test, you can inject an anonymous inner class that implements the single method of Provider<T> to return a constant value easily enough. Our code base has a SimpleProvider<T> class that wraps a given object in the Provider interface.

Pro: Allows you to construct the object in the main construction phase. Unit testing is pretty easy.

Con: Details about dependency creation issues are leaking into the class when they should entirely be the concern of the factory. Too bad if the class is already written and accepts directoryName rather than directoryNameProvider already.

Despite the seemingly long list of cons, this is an option I use alot. It is my opinion that there is a missing language construct here.

2. Construct the troublesome object later

You can enter an inner scope when you know more. Within a run-phase method, you can enter a new scope. This means that you go through a whole new mini-construction phase, and then a mini-run phase. Ths is similiar to what happens in your application main() but at a smaller level.

Pro: Class receiving the dependency remains pure.

Con: Entering and exiting too many scopes can make the application and object life-cycles difficult to understand.

3. Use a method argument

You can decide that directoryName is to be a method argument and pass it to your class during the run phase rather than trying to inject it as a constructor argument. This is effectively deciding not to use dependency inject style for this occasion.

Pro: Simplicity

Con: Class that passes directoryName as a method parameter is tightly coupled to the class that needs it. It will be very difficult to implement an alternate implementation that depends on say, a database connection.

These are matters that I have been considering alot lately, so I'm interested in any comments or edits. Are there any other options?