How to pass a configuration parameter to a singleton class ?
Hi,
I am implementing a singleton class which should accept a parameter when first creating its instance.
I am currently using a static public field which is populated by defaut by a static final field but can be overidden by a calling class before getting a first instance.
Is this design OK or is there a better way to handle this ?
Thanks
Here a sample of code
publicclass ConfigurationManager{
privatestaticfinal String DEFAULT_CONFIGURATION_FILE ="/conf.xml";
publicstatic String configurationFile = DEFAULT_CONFIGURATION_FILE;
public Parameters parameters;
privatestatic ConfigurationManager instance;
staticsynchronizedpublic ConfigurationManager getInstance(){
if (instance ==null){
instance =new ConfigurationManager();
}
return instance;
}
private ConfigurationManager(){
ConfigurationParser configParser =new ConfigurationParser();
parameters = configParser.parseConfigurations(configurationFile);
}
...
}
Calling code would be
ConfigurationManager.configurationFile ="/junit/config/Config.xml";
ConfigurationManager confManager = ConfigurationManager.getInstance();
[2137 byte] By [
fif2006a] at [2007-10-2 9:29:14]
Why have a member variable at all? Just pass the parameter as - you guessed it! A parameter!
ConfigurationManager confManager = ConfigurationManager.getInstance("/junit/config/Config.xml");
Not that it matters much. A bigger problem is that you are limiting yourself as to the form of the configuration data. Your parameter should be an InputStream rather than a String.
ConfigurationManager confManager = ConfigurationManager.getInstance(new FileInputStream(new File("/junit/config/Config.xml")));
Drake
> ConfigurationManager confManager = ConfigurationManager.getInstance("/junit/config/Config.xml");
It doesn't make much sense, IMO, to pass the parameter in getInstance().
This would be confusing to anyone who passes in something else, and would be expecting, perhaps, a different instance.
I don't have a better suggestion at the moment, but based on the two options above, I would be more inclined to implement something closer to the first solution.
/kl
Liggya at 2007-7-16 23:35:47 >
Besides, that implementation of Singleton is wrong.Google for "Singleton double checked locking"%
> Besides, that implementation of Singleton is wrong.> > Google for "Singleton double checked locking"> > %Hmm? The method is synchronized, that should be correct, no?
> It doesn't make much sense, IMO, to pass the
> parameter in getInstance().
> This would be confusing to anyone who passes in
> something else, and would be expecting, perhaps, a
> different instance.
It isn't obvious to me what the OP's design is. Every time somebody passes in a different parameter, a new "singleton" instance is created to be given out to subsequent callers who don't pass in a parameter? Or is it supposed to be lazy initialization, where the "singleton" instance is only created the first time a parameter is passed in, and subsequent passing in of parameters fails somehow?
The original problem was how to affect the configuration file used by the singleton, but this thread is about how to implement a bad solution to that problem. I would solve the original problem by using a system property containing the name of the file. If the system property is present at initialization time, then the class would use it. If it isn't present, the class would use some default. That allows users to override the configuration file in a straightforward and unconfusing way.
> > Besides, that implementation of Singleton is
> wrong.
> >
> > Google for "Singleton double checked locking"
> >
> > %
>
> Hmm? The method is synchronized, that should be
> correct, no?
Gotta read this:
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
%
System property sounds like a good and easy way to resolve my issue.Just for the record, why the use of a static field is not recommended in that case besides the fact that a system property is much more flexible.
> Gotta read this:
>
> http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleChe
> ckedLocking.html
>
> %
I have read that, the OP's code doesn't do DoubleCheckedLocking, it locks every time, like the second snippet in that article. Unless I'm missing something?
Gotta admit that it was a knee-jerk reaction, because I never bother with delaying the creation of the instance that way. I don't see the savings that results from waiting until the singleton is used for the first time. I assume that if that Singleton appears in an app that somebody will want to use it. I'm an eager instantiator.
When I write a singleton, I do it more like this:
public class Singleton
{
private static final Singleton instance = new Singleton();
private Singleton() {}
public static final Singleton getInstance() { return instance; }
}
No synchronized blocks, no fooling around, no double checked locking.
%
