Question

I’m working on a kind of parameter values parser library. I’d like to have an Parser defined as follows:

public class Parser {

    private ValuesConfiguration configuration;
    private ValuesProvider valuesProvider;
    private ValuesMapper valuesMapper;

    public Parser(ValuesConfiguration configuration) {
        this.configuration = configuration;
    }

    public Result parse(String parameterName) {
        List<Values> values = valuesProvider.getValues(parameterName);
        // do other stuff on values
        // ...
        return valuesMapper.transformValues(values, configuration);
    }
}

I’d like this library clients to be unaware of ValuesProvider and ValuesMapper default implementations and use it like

Result result = new Parser(myConfig).parse("sampleParam");

Although there must be possibility to set their own implementations when needed. I wonder how and where should I init those default implementations and still let clients to set their own if they want. I don’t want to stick to

new DefaultValuesProvider()

etc. in constructor, because default implementation would e.g. access filesystem, so that it would be hard to test (mock them out). I know I can use setters (like in DI) but what about defaults?

EDIT:
After your all answer, I guess it is best here to have setters to allow clients to provider their own implementations of ValuesProvider and ValuesMapper. But how to create default implementations? I’d like to decouple instantiation from logic, so I don’t want to use new DefaultValueProvider() here. Is the factory pattern applicable here? If so how and where should I use it?

Answer 1

How about:

public void setValuesProvider(ValuesProvider valuesProvider) {
    this.valuesProvider = valuesProvider;
}

public Result parse(String parameterName) {
    if (valuesProvider == null) {
        valuesProvider = new DefaultValuesProvider();
    }

    List<Values> values = valuesProvider.getValues(parameterName);
    // do other stuff on values
    // ...
    return valuesMapper.transformValues(values, configuration);
}

As Mark points out, constructor injection might be the better way to go. That would look as follows:

public Parser(ValuesConfiguration configuration) {
    this(configuation, new DefaultValuesProvider());
}

public Parser(ValuesConfiguration configuration, ValuesProvider valuesProvider) {
    this.configuration = configuration;
    this.valuesProvider = valuesProvider;
}


public Result parse(String parameterName) {
    List<Values> values = valuesProvider.getValues(parameterName);
    // do other stuff on values
    // ...
    return valuesMapper.transformValues(values, configuration);
}

I also agree with his summary of advantages:

This would enable you to make the dependency final/readonly. Property Injection provides quite weak guarantees about invariants – e.g. you could keep changing the dependency on the same instance, and that’s probably not what you want.

However, there are also disadvantages:

1. The number of constructors is exponential in the number of optional parameters, causing a lot of delegation and duplicated JavaDoc for the parameters. Therefore, I’d only use constructor injection if there are few optional dependencies. You have 2, which about my pain threshold for this kind of thing.
2. Constructor injection ist not very subclassing friendly, as the subclass constructors will have to redeclare the super class dependencies. In your case, a subclass that wishes to expose all configuration options will need 4 constructors … and if it adds an optional parameter it better shouldn’t to this with constructor injection, as this would require another 4 constructors.

My recommendation therefore is to use setter injection, and if it is necessary to prevent the reassignment of dependences, do:

public void setValuesProvider(ValuesProvider valuesProvider) {
    if (this.valuesProvider != null) {
        throw new IllegalStateException("Dependency already set");
    }
    this.valuesProvider = valuesProvider;
}