Re: Initializing Singletons
On Thu, 08 May 2008 08:02:07 -0700, Daniel Pitts =
<newsgroup.spamfilter@virtualinfinity.net> wrote:
[...]
public static SingletonClass getInstance() {
if (instance == null) {
instance = new SingletonClass();
ConfigFileReader config = new ConfigFileReader(instance);
config.read();
}
return instance;
}
SingletonClass() now should do nothing, or at least only construction =
=
related activities.
getInstance() will never return an uninitialized instance.
I guess that depends on your definition of "uninitialized". If we assum=
e =
that the work ConfigFileReader does is part of the initialization, then =
=
that's not true, as "instance" is set before initializing the =
ConfigFileReader. Some code could call getInstance() before =
ConfigFileReader.read() returns, resulting in it receiving the value of =
=
"instance" before whatever ConfigFileReader is supposed to do has happen=
ed.
ConfigFileReader gets an explicit instance to read into. Much more =
flexible for unit testing, etc...
I wholeheartedly agree with this (and your other comments about =
singletons, for that matter). And in fact, using this technique, you no=
w =
have the option of moving the assignment to "instance" after the =
initialization of the ConfigFileReader, addressing the concern above.
Of course, the whole thing as shown here still suffers from reentrancy a=
nd =
thread safety issues. But at least the new reentrancy issue is a matter=
=
of redundant initialization, rather than insufficient initialization. I=
=
guess that's a discussion for another day. :)
Pete