One of the dangers of the singleton pattern is that it encourages the developer to not make important design decisions and allows them to write lazy code on the assumption that "there will never be more than one". By reaching for the singleton pattern so soon, they are essentially allowed to skip the question "Should this really be a singleton?" in the first place. This can later become one of the pains of refactoring when they find out that they actually need two of their singleton; not only do they have to work out access to each of the new instances, lifetime issues, etc, they also have to re-write the former-singleton itself, and likely, some or all of its dependants and dependancies.
I did, in fact, used to be a proponent of the Singleton Pattern. In fact, I was finally convinced of its worthlessness only 2-3 months ago during a similar discussion, and have literally deleted it from my toolbox of code snippets. If I ever find myself feeling the need for one again, I have to hop on the net to find an implimentation (to make sure I've re-implimented it correctly) and copy it into my codebase. I don't expect that I'll ever feel that temptation, but I've made this decision to literally force myself to evaluate the need. The development world would probably be better off if all references to "Singleton" were banished from the internet, and one would have to drive to the local library or delve into the depths of the University Archive to find such information.
You should really ask yourself the question "Is it better to protect myself and my users from the harm that the Singleton Pattern encourages, or to protect them from creating two instances?"
Local Singleton?
Quote:Original post by Antheus
Singletons come from Java.
Sorry to say, this isn't true. The GOF book used C++ and Smalltalk for its code samples. They might well be ridiculously *popular* in Java code, but they weren't invented by the Java community, nor are they anything like necessary in Java - there is an equivalent to the C++ namespace trick, namely 'static' abuse. And, wouldn't you know it, the Java standard library uses this trick: see for example the Math class.
Quote:Original post by Gage64
Then why do programming languages have constructors, destructors, access specifiers, etc. if not to ensure a programmer doesn't do something he shouldn't do (forget to call an init()/shutdown() function, access a private variable it shouldn't touch, ...)?
First, many languages that have these conveniences don't prevent you from messing around with attributes in more direct fashion. (My current favorite language, Python, provides no real data hiding or access restrictions/enforcement.) Secondly, even languages that do attempt to restrict you can be hacked - and in some cases trivially so - by a sufficiently determined programmer.
Those features are conveniences. As a convenience, the option for the client programmer to restrict the number of instances of a type that may exist is cool; as a restriction decided on by the API author, decidedly not cool. Savvy?
You guys mentioned various times in this thread that you guys would make a check at compile time to make sure its singular...
How would you do that? (This is mostly out of curiousity)
How would you do that? (This is mostly out of curiousity)
Quote:
TheGangster - The whole point of this is to avoid using the normal singleton. Re-read my post.
Sorry misunderstood your idea.
By using "your way" you will never know what the instance is, you will only be able to know that there is an instance and that it can be deleted.
jpetrie - I understand that you and others don't quite like Singletons, but I am still new and I would like to learn a bit more about it, why not use it?
I agree that sometimes it's misuse, but other times it's necessary to simplify things, or what am I not getting?
Author
Quote:
I've been writing a lot of stuff assuming I already linked my singleton article... but apparently I had not. I suggest you read it, it goes into some of my points in more detail than I've expounded upon here.
I have actually read your article but I guess I didn't fully understand it. By the way, I've also read your other articles and really liked them. I hope you'll write more soon.
Quote:
I don't want to sound harsh, but perhaps you should consider the wisdom of arguing software design with established software developers with years of experience?
I wasn't really arguing with you (BTW, I'm 23 but like I said, I have very little programming experience). I've read a lot of your replies on these forums and understood fairly quickly that you know what you're talking about [smile]. In fact, I really hoped that you'll reply to this topic and I'm glad you did.
I'm sorry I was stubborn. I guess I wanted to hope that this idea is not completely useless, but most of all I wanted to understand your arguments more in depth. To some extent I did (mostly because of your last post), but I now realize that to truly understand them I need more experience (probably years of it). I will definitely come back to this thread in the future.
What I'll take away from this is that singletons are harmful in ways that I don't fully understand yet, so I should avoid them even when they seem appropriate (because, in fact, they are not). This will be difficult because it looks like avoiding them isn't always easy (for someone without a lot of experience), and it will be somewhat annoying because I don't like doing things blindly (that is, without fully understanding why I'm doing them), but looks like it will be worth it and hopefully as a result I will become a better programmer and will be able to convince others to do the same.
Thanks to everyone for their insight and advice. I hope we'll have many fruitful discussions in the future. [smile]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
