Static vs Single Pattern

[Jyotika Kapoor]

Hi all,

Have this small doubt The Single Pattern ; helps in creating a single object which will be shared among different classes , the static variable can be used to achieve this, then why do we a singleton pattern at all , i mean if its just about one copy across the classes.



Thanks in advance
Jyotika

[Pat Farrell]

The Singleton pattern was popular last century when the Gang Of Four patterns book came out. It is no longer considered a good thing to use.

Using just static values inside a class, or static classes, is also considered poor design these days.

Each of these approaches are just global variables, and global anything makes testing much harder, and can make bugs very hard to find.

Its much better to use a Factory and explicitly get what you want.

[Janeice DelVecchio]

The concept behind the Singleton pattern is to have a class(object) that can only be instantiated one time. The class itself is in charge of keeping track of the instance, and the constructor is private.

Although static variable has one instance per class, conceptually it's a bit different. The Singleton is an entire object (knows things and does things) that only makes sense to be instantiated one time. A static variable can hold a reference to an object, but that doesn't mean that object can't be instantiated somewhere else simultaneously.

I make no assertions that the Singleton pattern should or should not be used in practice. I think that making a blanket statement that it's not good to use doesn't take into account all applications. I'm sure there are situations that would make sense to use it.

[Pat Farrell]

Janeice DelVecchio wrote:I make no assertions that the Singleton pattern should or should not be used in practice.

I have no problem making the blanket statement: if you think you need a Singleton and you don't have ten years experience writing Java, then you don't need it.

I will grant that there are very rare cases when it can be used well. But most of the time, its a really bad idea.

Just because its in the Gang of Four book doesn't make it a good idea.

[Jyotika Kapoor]

i agree to what you say , just wanted to know why singleton pattern is required at all when we can achieve the same through static.


Regards

[Pat Farrell]

Jyotika Kapoor wrote:i agree to what you say , just wanted to know why singleton pattern is required at all when we can achieve the same through static.

Its not "required"

And "achieve the same through static." is also a bad idea.

If you google for double checked bug for singletons, there is a fairly complete explaination on the IBM website about Java

[Ulrika Tingle]

Jyotika Kapoor wrote:
Have this small doubt The Single Pattern ; helps in creating a single object which will be shared among different classes , the static variable can be used to achieve this, then why do we a singleton pattern at all , i mean if its just about one copy across the classes.

Singleton probably is more motivated in a language like C++ than Java.

But I'd say in Java you use a Singleton for the same reason you use getter/setter methods. It provides a thin abstraction over accessing "naked" variables. Whether you want this abstraction or even need it is up to you. Nobody forces you to use setter/getter methods and nobody forces you to use a Singleton.

On the rare occasion I need one global object I prefer a Singleton mostly because it's selfcontained and the OO apparatus can be used. It creates and instantiates itself and it's guaranteed to be there when you start using it and you can be 100% sure there's just one object created. The last time I used it was for a global "postoffice" service, like

public enum Mainmail implements IService<MainParcels> { // enum Singleton implementing a postoffice
	INSTANCE;
	
	private final IService<MainParcels> service = new Service1<MainParcels>(); // delegated implementation
	
	public void postAsync(IElement<MainParcels> packet) { // send packet via the event-dispatching thread
		this.service.postAsync(packet);
	}

	public void sendSync(IElement<MainParcels> packet) { // send packet directly
		this.service.sendSync(packet);
	}

	public void attachBox(IVisitor<MainParcels> box) { // add mailbox (listener for packets)
		this.service.attachBox(box);
	}

	public void detachBox(IVisitor<MainParcels> box) { // remove mailbox
		this.service.detachBox(box);
	}

}
// example of usage
Mainmail.INSTANCE.postAsync(.............); 

I'm using the enum implementation of Singleton which I find neat. The enum implements an interface describing what services a postoffice should offer. Also delegation is used so that it's easy to plug in a new postoffice implementation should the need arise.

I could've done the same using a "global" static variable but to me the Singleton approach is more attractive.

[Pat Farrell]

Ulrika Tingle wrote:Singleton probably is more motivated in a language like C++ than Java.

But I'd say in Java you use a Singleton for the same reason you use getter/setter methods. It provides a thin abstraction over accessing "naked" variables. Whether you want this abstraction or even need it is up to you. Nobody forces you to use setter/getter methods and nobody forces you to use a Singleton.

I agree that its more useful in C++ than in Java.

While nobody should force you to use a Singleton pattern in Java, if you work for me, I'll force you to not use it, as its bad engineering.

Some will argue that this is a religious argument, and so I'll stop here since this is "Beginning Java" but I think its an engineering argument.

[Ulrika Tingle]

Pat Farrell wrote:While nobody should force you to use a Singleton pattern in Java, if you work for me, I'll force you to not use it, as its bad engineering.

Some will argue that this is a religious argument, and so I'll stop here since this is "Beginning Java" but I think its an engineering argument.

My approach is that you should avoid global data but when you need it it's better to use a Singleton than a "naked" global variable.

Please feel free to comment on my example. How would you implement a mailing system that's used throughout a fairly large program? I've found that a global access point, a main post office, is superior to any alternative I could come up with. I could've passed around a post office object but that's very tedious and it actually increases coupling between modules and classes.

Here's your chance to not being "religious" in your views. It's a concrete example. What's your better alternative to using a Singleton? If you use simple language to explain it I'm sure also beginners will benefit from your insights.

[David Newton]

(As an aside, you can use a single instance of an object, without necessarily caring if it's a singleton or not, by injecting it into things that need it. It makes testing easier, avoids passing it around, and avoids being tied to a particular implementation. The injected object *may* be a singleton, but doesn't *need* to be--whether or not it is is dictated by its application.)

[Janeice DelVecchio]

I'm just asking, and I don't wanna stir up any arguments here....

If you have lots of people that are programming pieces of an application that all use something that has to be instantiated only one time (say a timer, or the post office, et cetera), how do you manage the possibilities that someone might try to instantiate it again without using a singleton pattern?

I only have a (pretty decent) foundation level understanding of Java, and have studied patterns briefly in a class... I actually used the Singleton pattern in my current project to create a single connection with a database. Part of the spec was to implement design patterns and I figured it was a pretty easy one to implement (I also used the MVC.... I thought I was going to kill someone )

[David Newton]

Janeice DelVecchio wrote:[...] how do you manage the possibilities that someone might try to instantiate it again without using a singleton pattern?

You don't--but that's a different issue than whether or not singletons are a Good Idea.

[Mike Simmons]

Janeice DelVecchio wrote:I'm just asking, and I don't wanna stir up any arguments here....

Hey! Them's fightin' words here... ;)

[Ulrika Tingle]

Janeice DelVecchio wrote:
If you have lots of people that are programming pieces of an application that all use something that has to be instantiated only one time (say a timer, or the post office, et cetera), how do you manage the possibilities that someone might try to instantiate it again without using a singleton pattern?

One way to hide types is to make them private to a package. If a class, interface or enum has the default access modifier it can only be used from within the package where it's defined. So they're hidden from outside use.

This is the case in my example. The Mainmail enum Singleton is publicly exposed but the actual implementation, the Service1 class is package private so it cannot be instantiated outside its package.

[Ulrika Tingle]

Pat Farrell wrote:
While nobody should force you to use a Singleton pattern in Java, if you work for me, I'll force you to not use it, as its bad engineering.

Well Pat Farrel, I don't work for you so I'm using Singetons when I feel they're appropriate.

Please explain why my postoffice Singleton is bad engineering and what you would do instead. I know the answer already of course. You don't have the faintest idea. As is so often the case, faced with a practical dilemma the loud speaker of dogmatic views suddenly is very silent.

And that's why I'm pragmatic on this issue. Although global data should be avoided, there will always be a need to handle them and Singletons are the best alternative (so far).

[Mike Simmons]

[John de Michele]

Janeice:

One way to control object creation would be to create a factory class. Instead of instantiating objects of the target class directly, you would call a method from the factory class to get object references. The factory could then internally control whether or not you got a reference to a new object or an existing one.

John.

[Janeice DelVecchio]

John de Michele wrote:Janeice:

One way to control object creation would be to create a factory class. Instead of instantiating objects of the target class directly, you would call a method from the factory class to get object references. The factory could then internally control whether or not you got a reference to a new object or an existing one.

John.

Thanks John....

But how is that, design wise, different than using a singleton design pattern?

[David Newton]

[Janeice DelVecchio]

David Newton wrote:

As a side note....
Love this smiley

[Jimmy Clark]

The infamous Simpleton design pattern is a non-object-oriented way to write "structured" procedural code. It is typically used by programmers that either do not significantly understand object-oriented design principles or are lazy buffoons that don't care about the code they write.

This pattern should never have been included in the GOF book, and was simply a bone to get individuals to start to think about patterns period.

Just me two cents

[Ulrika Tingle]

James Clarks wrote:The infamous Simpleton design pattern is a non-object-oriented way to write "structured" procedural code. It is typically used by programmers that either do not significantly understand object-oriented design principles or are lazy buffoons that don't care about the code they write.

This pattern should never have been included in the GOF book, and was simply a bone to get individuals to start to think about patterns period.

Just me two cents

Apart from misuse, don't you think there are any valid uses of Singletons at all? If your answer is no I challenge you to come up with a replacement for the "postoffice Singleton" I presented in a previous post.

Assuming that you don't belong to the group of programmers who "do not significantly understand object-oriented design principles or are lazy buffoons" it should present no problem for you.

[Janeice DelVecchio]

Alright, I'm now trying to figure out if this argument has any documentation either way.

If there is really a reason to not use Singletons, then I would like to see sources, likewise for resons to use them.

Are there any websites I can look at? I would like to figure this out..... all the sites I have looked at (including the ibm site) refer to problems in older versions of Java, not 5 or 6. Is this an older problem? Has it been fixed? Why is the factory class better?

If the singleton is so bad, why do they still teach it to students in programming/design classes?

[David Newton]

Janeice DelVecchio wrote:Alright, I'm now trying to figure out if this argument has any documentation either way.

Google "Singleton considered harmful", "singleton considered stupid", and so on. Finding information on this topic is trivial.

likewise for resons to use them.

That will prove more difficult.

If the singleton is so bad, why do they still teach it to students in programming/design classes?

Because it exists?

[Janeice DelVecchio]

David -

I did google "problems with singleton pattern", "java singleton pattern", and "double checked locking"

All of the reliable sources on the bugs I am presuming you're describing (because you haven't given real reasons yet) I found were pre JDK5.

Is this an old problem? Has it been fixed?

Thanks for your time

[Jimmy Clark]

If the singleton is so bad, why do they still teach it to students in programming/design classes?

Interesting question. Only the actual teachers would be able to precisley tell you why they teach the Simpleton design pattern.

Here is my take.

Many tenured professors that have been teaching Computer Science for decades rarely have significant real-world experience building actual software systems. They are proficient at teaching Computer Science basics, which haven't change much in the past forty years. However, design and the art of modern software design might escape them.

Then you have teachers that may have experience with Structured Programming and need to include something related to OO in their course, so they shoot for the easiest thing that they can understand quickly. Hence the name, Simpleton

Lastly, in my training classes, when I have them, I sometimes do cover the Simpleton pattern. But, I teach not to use it and to avoid implementing it by creating more elegant OO designs.

Hope this helps!

[John de Michele]

Janeice:

It isn't a whole lot different, really. The factory class could limit the number of objects to say, 10 or 20 or something other than 1 (say in a connection pool, or something similar).

John.

[David Newton]

@Janeice: I'm not sure how you read the main hits to that and came away with Singletons being a < JDK 1.5 problem, maybe you could elaborate?

[Janeice DelVecchio]

David Newton wrote:@Janeice: I'm not sure how you read the main hits to that and came away with Singletons being a < JDK 1.5 problem, maybe you could elaborate?

http://www.ibm.com/developerworks/java/library/j-dcl.html

http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

http://java.sun.com/developer/technicalArticles/Programming/singletons/

Two of these articles were written pre JDK 5, and I think it's the 2nd one that explicitly states that labelling the instance volatile (which wasn't available until Java5) and synchronizing the getter method fixes the problem.

[David Newton]

"The" problem? What do you think "the" problem is? (Double-checked locking, btw, isn't just a singleton issue, and as the reference you post explains, is still an issue. Issues with Singleton extend beyond simple instance creation issues, though.)

I'd consider reading some of the other articles, like:

http://steve.yegge.googlepages.com/singleton-considered-stupid
http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/
http://tech.puredanger.com/2007/07/03/pattern-hate-singleton/

[Janeice DelVecchio]

You never specifically said what the issue was to begin with and you told me to google it, so I did. That's what I came up with. I told you I have only a foundational level understanding of Java and Design Patterns, and I don't know what it was you expected. It's unfair of you to corner/embarrass me and say:

"The" problem? What do you think "the" problem is?

As if I were to know there was more than one aspect of the issue.

If you were more specific earlier in this thread, maybe we wouldn't have had to beat around the bush to get you to give me some sources to read, and maybe I'd understand more that it's a multi faceted problem. I feel like I have been asking you for two days why using this pattern is such an issue, and you couldn't tell me anything except "google 'singleton considered stupid.'" I've now gotten incredibly frustrated and I feel like you thought I should "just know" what the issue(s) are.

EDIT:
Additionally, the sites you directed me to are blogs. They are not permissable in the academic realm and are considered opinion rather than fact. Have there been any books published about design patterns that I could check out? How about academically sound websites?

[Jeff Storey]

Great article references here, David. I want to go back to a post earlier on where you mention the idea of using injected singletons (I wrote blog post on that a few months ago http://jeffastorey.blogspot.com/2009/08/spring-managed-singletons-for.html). It's actually an excellent point, not to be overlooked as an aside. Allowing a container (such as Spring) to manage your singletons is useful for a number of reasons:

1. Classes are not asking for objects with tons of references to getInstance, rather they are given a reference. An object should be concerned with its own behavior and not about how ti gets the objects.

2. It makes objects much more testable. Mocking singletons is very difficult and may discourage test writing.

3. If later on down the line you realize that something that was a singleton shouldn't have been, or vice versa, it's much easier to change that using injected singletons.

On a side node, using a practice like test driven development will really help discourage singletons. When you write the test first, it's unlikely you'll write the test around singletons.

That's my input for what it's worth.

Jeff

[David Newton]

Janeice wrote:you couldn't tell me anything except "google 'singleton considered stupid.'

And that article didn't show up when you did? Both that, and "singleton considered harmful", come up with the articles I linked to, including on a bare machine that isn't mine and doesn't have Dave-tuned search results--I didn't use those phrases arbitrarily.

I don't know how else to ask you what you consider "the" problem to be other than to just ask--and you didn't answer, so I still don't know.

I have no idea what, if any, books talk about anti-patterns these days, and I'd sure be nervous if a school didn't let me use anything other than books as reference material. Heck, even back in the days of Usenet we could reference news articles. References, just like books, are just that--references. There's nothing inherently more "referential" about a book as compared to a blog post. Having read Moon People in its entirety I can assure you that having an ISBN is not a guarantee of quality.

You might be able to find some research papers on the ACM site--still not books, but perhaps your school would be more amenable to allowing the use of what are essentially long blog posts submitted for a grade. Personally, I haven't found the ACM's digital portal search to be overly helpful (which strikes me as ironic), but it is what it is.

[David Newton]

@Jeff: It was an "aside" more in that it was tangential to the current (ridiculous) thread on whether or not Singletons are the end of the world as we know it. Lots of people that "don't use Singletons" use them, they just don't manage them themselves, making them seem a lot less like Singletons. And when they're being injected it doesn't necessarily matter anyway (as you said) whether they are or not, making the argument somewhat less interesting.

[David Newton]

@Janeice: (Now I'm curious as to what makes a blog "opinion" and a book "fact"... books are just longer opinions. What if the blog author was someone who also wrote a book? Or is the requirement that it be physically present in a printed book? What if it's a book of blog posts? A book that's only available electronically? How long does something have to be before it counts as a book? What if a book uses a blog post as one of its references (which happens quite frequently these days)? Some of the most current, up-to-date, and thought-provoking material these days will *never* appear in print--should we just ignore it?)

[Janeice DelVecchio]

I'm just saying that if you can only come up with blog sites, it seems like it's an opinion rather than fact.

One of the blogs, specifically your "stupid singleton" blog, was published before JDK5 (rather, the same day it came out.... which means it was written before it came out). The others were sourced before JDK6.

The fact is, blogs are one person's opinion. Just because you find a bunch of people with the same opinion doesn't mean that anything is more than just a consensus by a few people. It hardly points to a general consensus of the "wrongness" of the pattern itself.

I never said that it HAD to be a book, but typically, blogs are more of an informal source than a formal source. Reliable sources are .edu sites, published journal articles, respected magazine articles, books.... you can't use blogs, wikipedia, .com sites, or other informal sources to write a term paper. When you discuss things in a class, people pick your sources apart. A blog (unless the "blogger" were a highly respected person in the field) would simply not hold up to that kind of nitpicking.

I'm now trying to figure out if there's any fact behind this opinion. I have not been able to find any current reliable sources that outline, specifically, what the problem is.

To me, until there are reliable sources, it's just a few people with a common opinion.

Really, you haven't even been able to give me any information either. You rant and rave and say none of your employees are allowed to use singletons... but you haven't made any plausible argument at all. What do you say when they ask why? You send them to a bunch of old blogs written by people who think similarly?

[David Newton]

Please pay attention to who you're replying--I neither said anything about my employees' use of Singletons, nor have I ranted and raved.

I *still* don't understand your focus on the JDK5/6 thing--JDK-related issues aren't being discussed in any of them. I'll list them again, in case somehow I messed up earlier and posted links to different articles:

http://googletesting.blogspot.com/2008/08/root-cause-of-singletons.html

This one talks about global state and dependencies. It also talks about singletons that are "ok", and singletons that are "semi-ok".

http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/

This one talks about dependencies and interdependencies/collaborators.

http://steve.yegge.googlepages.com/singleton-considered-stupid

This one is back to global state, inheritance, syntactic noise, and a small amount of threading at the end.

In any case, almost none of those things are JDK-dependent (and double-locking is still broken, as noted in the (IBM?) article you linked to, even post-JDK5).

If the pieces I linked to don't provide any useful input as to why (a *lot*) of people find Singletons distasteful, then I doubt any further information I provide will be of any benefit whatsoever. The blog posts sum up the bulk of what is wrong with Singletons--I can't make it any plainer than what you've already read. And I believe you seriously underestimate the number of people that believe similarly. Perhaps we're all delusional--*I* don't think I am, but then, if I'm delusional, I wouldn't necessarily *know* that I was.

Books are just opinions too, you know, and I don't understand why you don't understand that. If I had put a paragraph in my book about how singletons reduce testability would that count as a reliable source? Even though it's just my opinion, arrived at after two and a half decades of professional development experience? (I don't specifically address singletons, since I focus on injectability--what is being injected is of much less importance to me for the reasons Jeff Storey elaborated on.)

In any case, I'm done--this has degenerated into little more than personal invective and general casting of aspersions.

If you want to continue the discussion, please open a thread in a more appropriate forum.

Edit: To answer your specific question, "what do I say when people ask 'why'?": I tell them why. My reasons why are the same, more or less, as those outlined in the blog articles above. When I explain the reasons (which consist largely of the collaboration and testability issues), or have them read the above articles they also understand why, because they're usually also working to build relatively large, stable, testable, extensible applications, and these things matter to them as well.

The reasons listed in the above articles are largely concerned with things applicable to that type of development environment. And, as I stated above, and was stated in one of the "opinion" pieces I listed, *some* kinds of singletons *are* okay, under controlled circumstances. Also, as I alluded to in my original "aside", people use singletons without necessarily realizing (or caring), like in the case of Spring-managed singletons. When these are injected into collaborators, however, one of *my* biggest concerns about singles is eliminated.

The arguments listed above stand on their own. Does the nit-picking of sources go no further than someone saying "I don't know who that is--the opinion is useless"? Or do these discussions actually center on discussing problems encountered building robust, extensible, testable software?

[salvin francis]

I think a bit differently so bear with me,

I didnt go thru the entire conversation, but here are things I wish to contribute:

1. Singletons are implemented via a static object
2. Its a pattern, not an antipattern, there are a lot of cases where it makes sense to have singleton pattern rather than a factory class.
eg: an MDI application where the Main MDI controller is a singleton,
3. There are already implementations of singletons into the java framework [will someone care to elaborate this? i am pressed for time]

[Jimmy Clark]

KILL SINGLETONS ON SITE

If you are working with a small application running in a single JRE, then using the Singleton design might seem to make sense and maybe even be perceived as "good" design...lol

If you are ever possibly designing an enterprise application which may run on 10 to 20 JRE instances, then your Singleton design is flaw and will most likely be the source of resource contention and/or bottleknecks.

NOTE: If you start off thinking that the Simpleton is a good strategy then you most likely will never make it to the major leagues and never have to worry about it anyway. The choice is yours.

[Janeice DelVecchio]

I never said singletons were good or bad. I just don't know. Actually, my very first post said I made no assertions whether or not they should be used or not. I said I understood the basic concept of why someone would use it over a static variable. Rather, I think I just compared the two, not even made an assertion of why it should be used over a static variable.

What I said was that no one could tell me (on a foundational level) what the heck is wrong with using them. Everyone here has said "they're bad," "don't use them," et cetera.

I got links to blog posts from several years ago. Are these people respected in the field? I have no idea. No one said, "please see Joe Shmoe's blog, he's a such and such person in the blah blah industry for x years. He did studies for blah company."

When I questioned the sources, on an academic level, no one could defend the fact that the sources were blogs. No one could find a reputable source (or at least define what makes the blogs reputable).

If someone could tell me, in normal person language:
1: Why doesn't the JDK5 "volatile label fix" work to fix the singleton problem?
2: What, if any, are the problems with the Singleton pattern, exclusive of the issue of threadsafety (which is supposedly fixed by the "volatile" labeling)

I am really through with feeling like I have to defend myself. Just because I ask questions doesn't mean I'm questioning anyone's judgement, it just means I'm not going to take advice on face value no matter how long you've been following it.