[java] Singleton pattern in Java
Author
So we're saying, if you doing a Singleton in Java, the best way to do it is to simply use static classes? And this has no real disadvantages? Obviously the initialization issue is a non factor. I can't think of any goals of using a Singleton that haven't been addressed here.
I don't think all static classes makes it a single. The pattern (as defined by the GOF) like most things OO is about future proofing your code. Just because today you feel that the class should only have a single instance, doesn't mean tomorrow you won't decide actually your going to maintain multiple contexts in your enterprise version and each one is going to need its only instance.
The single static get method returning a statically instantiated single instance of the class is meant to isolate your code from getting dependent on statics. If you're absolutely sure there will never be multiple instances of the object (famous last words) then by all means use an all static class. If not, the Singleton is just a good pattern to avoid problems later.
Kev
The single static get method returning a statically instantiated single instance of the class is meant to isolate your code from getting dependent on statics. If you're absolutely sure there will never be multiple instances of the object (famous last words) then by all means use an all static class. If not, the Singleton is just a good pattern to avoid problems later.
Kev
Quote:Original post by kg
I don't think all static classes makes it a single.
It indeed doesn't.
Quote:The pattern (as defined by the GOF) like most things OO is about future proofing your code.
It indeed is.
My argument is that this justification is backwards; if anything, using a design pattern should be the result of reworking something *into* a design pattern, for "past-proofing" - i.e. noticing a problem and making sure it doesn't happen again.
Quote:Just because today you feel that the class should only have a single instance, doesn't mean tomorrow you won't decide actually your going to maintain multiple contexts in your enterprise version and each one is going to need its only instance.
I have only pity for those who work on projects big enough that this is a real concern (although I acknowledge that such projects certainly do exist). :(
Author
Well, I think there's better reasons than just preparing for change:
"A simple approach to this situation is to use static members and methods for the "singleton" functionality. For these elements, no instance is required. The class can be made final with a private constructor in order to prevent any instance of the class from being created.
Unfortunately, this "static-singleton" approach falls short on several counts:
-We may require run-time information to prepare the static-singleton for use. It may be awkward to accomplish this--i.e., we must insure that the static-singleton is properly initialized before each use. This greatly increases the coupling between the static-singleton utility and its clients.
-Methods that are static cannot be used to implement an interface. Hence we lose a great deal of the power of Java's interface entity.
-All references to the singleton must be hard-coded with the name of the class. Hence there is no meaningful way to override the static methods. In other words, all static methods may as well be final."
From
http://radio.weblogs.com/0122027/stories/2003/10/20/implementingTheSingletonPatternInJava.html
Maybe it's a little outdated because it's old, but not sure.
"A simple approach to this situation is to use static members and methods for the "singleton" functionality. For these elements, no instance is required. The class can be made final with a private constructor in order to prevent any instance of the class from being created.
Unfortunately, this "static-singleton" approach falls short on several counts:
-We may require run-time information to prepare the static-singleton for use. It may be awkward to accomplish this--i.e., we must insure that the static-singleton is properly initialized before each use. This greatly increases the coupling between the static-singleton utility and its clients.
-Methods that are static cannot be used to implement an interface. Hence we lose a great deal of the power of Java's interface entity.
-All references to the singleton must be hard-coded with the name of the class. Hence there is no meaningful way to override the static methods. In other words, all static methods may as well be final."
From
http://radio.weblogs.com/0122027/stories/2003/10/20/implementingTheSingletonPatternInJava.html
Maybe it's a little outdated because it's old, but not sure.
Quote:Original post by ZahlmanIf you design something properly you can usually find many of the possible issues at design time, you can also identify and introduce opportunities for extensibility through design. I prefer to do my past-proofing in advance.Quote:The pattern (as defined by the GOF) like most things OO is about future proofing your code.
It indeed is.
My argument is that this justification is backwards; if anything, using a design pattern should be the result of reworking something *into* a design pattern, for "past-proofing" - i.e. noticing a problem and making sure it doesn't happen again.
It gets harder and harder to have meaningful debate here in the abstract, without context (i.e. a particular project) - so I will just drop in a couple of interesting wiki links and sign off from this thread. [smile]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
