Re: Singleton Design pattern with a twist - n00b
eladkatz@gmail.com wrote:
private static ConfigInfo confinfo;
public static setup(ConfigInfo cfg) {
if(instance == null) {
confinfo = cfg;
} else {
throw VeryBadException("Too late !");
}
}
Arne
thanks but the thing is - this means that whenever i get the singleton
(many places) i have to try/catch it and this will make my code very
hard to read and also much more complicated, there has to be a better
way...
Make it a runtime exception or better yet an error. And the setup is
only supposed to be called once, in main, unless you want that error's
stack trace and the message "Too late !" becoming eerily familiar to
you. It was the getInstance you want to use later. Of course you're in
for a fun session with NullPointerException if you forget to call setup
first.
More generally, why not use the static initializer and class loading
specification trick:
private static ConfigInfo info;
private static class Holder {
public static final MySingleton instance =
new MySingleton(info);
}
public static void setup (ConfigInfo inf) { info = inf; }
public static MySingleton getInstance () { return Holder.instance; }
public MySingleton (ConfigInfo info) { myInfo = info; }
private ConfigInfo myInfo;
....
The neat trick here is, Holder isn't loaded by the classloader until
there's an actual attempt to instantiate the class or invoke a static
method on it or access a static field or similarly. And then it's loaded
and its static initializer runs *atomically* -- i.e. thread-safely.
When that happens, the instance is constructed using the current value
of info, which of course is the last thing setup was called with before
the first call to getInstance executed. And null, of course, if setup
wasn't called soon enough.
The real beauty of it is that every later call to getInstance has the
blazingly fast performance of a single non-polymorphic, inlinable
function call and a single field access(!)...
Of course, for real generality, you create a DebugPolicy class -- not a
singleton -- and pass instances around as parameters, where they clutter
up method argument lists but allow you to use different ones in
different places, use a simple "debugPolicy = new OurPolicy(); ...
doSomething(debugPolicy) ..." in your main method, and so on. Of course,
a debugPolicy handled by multiple threads probably needs to synchronize
some stuff, aside from reads of read-only data. If it doesn't need to
have shared state across threads, giving separate instances to separate
threads makes sense. If you don't care about taking a huge performance
hit you can even make them thread locals and avoid the extra arg in all
your method signatures.
Or you can use a cute little buzzword-compliant singleton. Just please
pass on that bad batch of double checked locking that's been going
around. Anyone running a pre-1.5 JRE will have potential problems even
if you use "volatile".