If I have a singleton class with static members only and I'd like to ensure that nobody accidentally instantiates the class, would it make sense to declare the class abstract? Or instead should I leave it non-abstract but make the no-argument constructor private? Or both?
Which of these approaches would you recommend?
Thanks.
> If I have a singleton class with static members only
> and I'd like to ensure that nobody accidentally
> instantiates the class, would it make sense to
> declare the class abstract?
Anything strange happen if you try to make it abstract and compile it? If you haven't done it yet, please do so and let me know.
> If I have a singleton class with static members only
That doesn't sound like a "real" singleton.
> and I'd like to ensure that nobody accidentally
> instantiates the class, would it make sense to
> declare the class abstract? Or instead should I leave
> it non-abstract but make the no-argument constructor
> private? Or both?
The latter. Providing a single, private c'tor says pretty plainly, "Do not instantiate me." Making it abstract says, "Extend me and instantiate the child classes."
Could you describe what you mean by it not being a real singleton? If all members are static, and I'm just doing things like MyFactory.createClass() on it, isn't it a singleton (there's no reason, but no harm, in having multiple instances of MyFactory around)?
Please clarify my misunderstanding of the singleton pattern. Thanks.
> Could you describe what you mean by it not being a
> real singleton?
Although a class with all static members that can't be instantiated acts very much like a singleton, to my mind, a singleton is a single instance of a class. It's a minor point, and certainly debatable.
> If all members are static, and I'm
> just doing things like MyFactory.createClass() on it,
> isn't it a singleton (there's no reason, but no harm,
> in having multiple instances of MyFactory around)?
Wait, are you saying you *are* instantiating this thing? That you've got multiple instances operating on static variables? Ick. That's confusing and pointless. Either make it all static and non-instantiable, or a "real" singleton with non-static member variables and methods.
I have a question about singletons in general, actually. I've always wondered what are the advantages of implementing singleton in the second of the two ways shown below, as that's what always comes to mind when you hear Singleton.
It seems to be the primary way of doing it, so there must be several advantages in terms of design - could you please fill me in? My naive opinion tells me the first way shown below is less typing for the user of the singleton and for the writer of the singleton, but clearly it's got some drawbacks - I just don't know what they are.
-
MySingleton.method();
-
MySingleton singleton = MySingleton.getInstance();
singleton.method();
-
pros of using classical singletons (per Head First Design Patterns):
1) It ensures that one and only one object is instantiated for a given class.
2) It gives a global point of access like a global variable
3) It is only created when you need it (unlike a global variable) and thus wastes no resources if it is not needed.
4) Using a static self-contained class in place of a singleton can be a source of subtle, hard-to-find bugs often involving order of initialization of static code.
5) Global variables encourage developers to pollute the namespace with lots of global references to small objects.
The main advantage I know of for having a singleton implemented as an instance of a class (rather than a class with all static members) is that you get polymorphism.
MySingleton single = SingletonFactory.getInstance();
// which implementation of doStuff gets called is determined at runtime,
// by whichever implementation the factory returns.
single.doStuff();
For example, it's quite possible that any given implementation of java.sql.Driver might be a singleton. We require runtime polymorphism for these, which you don't get with static methods.
> pros of using classical singletons (per Head First
> Design Patterns):
>
> 1) It ensures that one and only one object is
> instantiated for a given class.
This is effectively the same as using a non-instantiable class with all static members. You don't have an instance, but you have exactly one of it.
> 2) It gives a global point of access like a global
> variable
Again, same thing with a non-instantiable class with all static members.
> 3) It is only created when you need it (unlike a
> global variable) and thus wastes no resources if it
> is not needed.
Again, same thing.
Also, Java does not have global variables.
Also, no variable in Java requires more than 8 bytes, and most are 4 or 2.
> 4) Using a static self-contained class in place of a
> singleton can be a source of subtle, hard-to-find
> bugs often involving order of initialization of
> static code.
Eh? Example please?
> 5) Global variables encourage developers to pollute
> the namespace with lots of global references to small
> objects.
What global variable? Java doesn't have global variables? How is a class full of statics any more a global than a "real" singleton?
>> 4) Using a static self-contained class in place of a
>> singleton can be a source of subtle, hard-to-find
>> bugs often involving order of initialization of
>> static code.
> Eh? Example please?
When I read #4, a situation I had encountered a while back occured to me. I think this is what he means, anyways.
I designed a static class (this was before I even knew what a Singleton was, but I've read up on it now) to "intercept" and "redirect" calls to System.out
Now, System is also a static class. What my static class would do is it would replace System's out member with MyClass's myOut member.
Most of my classes are extensively logged with calls to MyClass.log("blah")...
I encountered several problems with this, though. It seemed to me that "instantiation" of static classes on runtime is random? As in, I could sometimes get off a log() call and have it be redirected correctly, or sometimes it would go through the default System.out
But thinking about it... if the 'instantiation' (not sure of the correct term?) of static classes was random... then there would be a lot of errors concerning static classes accessing other static classes with static members?
Just my 2cents.
> I designed a static class (this was before I even
> knew what a Singleton was, but I've read up on it
> now) to "intercept" and "redirect" calls to
> System.out
>
> Now, System is also a static class. What my static
> class would do is it would replace System's out
> member with MyClass's myOut member.
Minor point: The System class is not static, and, most likely, neither is yours. Top level classes cannot be static. All the methods may be static, but that doesn't make the class static.
> I encountered several problems with this, though. It
> seemed to me that "instantiation" of static classes
> on runtime is random?
I don't know what you mean by "instantiation" here (perhaps class loading?), but whatever it is, no, it's not random.
Nice to know that. I didn't think to differentiate between "static classes" and a class with all static members. You are correct in your assumption that both are not static classes, thanks for pointing that out. :D
Yeah. That's exactly what I meant by instantiation. That's why I put it in quotations, lol. Had no idea what to call it! :)
Thanks for clarifying. =)
I usually like to use the Singleton pattern with private constructor (change of course the class name with something more meaningful):
public class MySingleton {
/** Singleton instance. */
private static MySingleton singleton;
public synchronized static MySingleton getInstance() {
if (singleton== null) {
singleton= new MySingleton ();
}
return singleton;
}
private MySingleton () {
// your code here
}
