This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002.
If you wish to participate in discussions, please visit the new
I agree, plus...
Posted by MIke Thomas on September 20, 2000 at 11:42 AM
Singleton is probably an overused pattern anyway. Many times all you need is a "static class" which offers non-stateful, centralized utility methods - no need to create a singleton in this case. Plus, in TP/app server environments, I feel singletons are to be avoided due to potential threading issues.
> Singleton pattern results in ONE "instance". Not just a class. As far as I know. And I haven't read the relevant article.
> Now, just calling Class methods doesn't mean you have a singleton.
> And your comment about "it's a matter of style and not procedural programming practise" is not correct. People do tend to use just the class methods becuase that's what they did in proc. langs.
> A true singleton should produce one and only one instance and messages should be sent to that instance and not the class.
> That's just my opinion, I could be wrong.
> > In an application I'm developing I have a singleton class
> > which provides basic services used throughout the application.
> > The singleton is implemented using statics. I do not believe
> > the question of object-oriented versus procedural programming
> > applies here. It is one of style.
> > For a singleton accessed in many places, ClassName.method()
> > seems to me to be more readable than
> > ClassName.getInstance().method. Since the concensus
> > is not to use statics for singletons I will probably change
> > it, but I am not completely convinced.