You can. But by placing this in the constructor you are making your object hard to test.
Instead you should:
init()
methodDependency injection frameworks give you these options.
public class ConfigurableObject {
private Map<String, String> configuration;
public ConfigurableObject() {
}
public void setConfiguration(..) {
//...simply set the configuration
}
}
An example of the 2nd option (best used when the object is managed by a container):
public class ConfigurableObject {
private File configFile;
private Map<String, String> configuration;
public ConfigurableObject(File configFile) {
this.configFile = configFile;
}
public void init() {
this.configuration = parseConfig(); // implement
}
}
This, of course, can be written by just having the constructor
public ConfigurableObject(File configfile) {
this.configuration = parseConfig(configFile);
}
But then you won't be able to provide mock configurations.
I know the 2nd opttion sounds more verbose and prone to error (if you forget to initialize). And it won't really hurt you that much if you do it in a constructor. But making your code more dependency-injection oriented is generally a good practice.
The 1st option is best - it can be used with both DI framework and with manual DI.