- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
I heard the illustrious Gang of Four wanted to include this as the Simpleton pattern, though in the end they just thought it would set a bad precedent.
Admin
Is Tinder like Grindr, only with the requisite number of vowels?
Admin
What's with the hate agaist disenvoweled brand names? Don't you know you can never be successful if your brand has more than 6 characters‽
Admin
I'm more interested in the recent popularity with misspelt words in general. Especially on here...
Admin
Of course that is not a Singleton class...
Did you know that the Singleton Class (as opposed to other patterns which manage instancing) is now considered an anti-pattern??? This is especially true of the Meyers Singleton implementation (which this post shows a broken implementation)
Admin
Everything has its people who "consider it harmful" or an anti-pattern. But I would would not say that it's common sense under software developpers that singleton is an anti-pattern. It's overuse maybe.
Admin
Using this abortion of an implementation would mean you first have to call the constructor, then getInstance()?
And you would have to do this everytime you wanted the instance? The first line was likely done when loading, then just calling getInstance() whenever. Or, anything else would be an even bigger WTF.
Admin
Most developers who actively study, publish and utilize Design Pattern based development strongly consider it an anti-pattern. Of course when you add in all the cargo-cult followers their numbers are dwarfed. Here are just a few of the many reasons:
It is very rare that at the conceptual level only one instance of a type of thing can ever exist across the universe.
Most implementations are NOT thread-safe, and the vast majority of "locking" implementations introduce significant overhead, which leads to caching, which leads to GC impact.
A Singleton Class is very hard to test properly at all levels (ranging from unit tests on the class itself to integration classes and DI issues)
In a FullTrust environment the implementations to not actually "Ensure" anything. It is just syntactic aspartame (tastes, like sugar, but can actually have negative health effects)
There are so many alternatives that have been created in the 20 years since the book was published (which was just supposed to be a representative sample of patterns that worked well in the environments that the authors work in at the time - not a global "holy book").
Admin
Which is, ironically, an antipattern in itself.
Mostly revolve arount bloated, parasitic and spooky action at a distance-fueled DI frameworks, from what I've seen.
Admin
You're just listing reasons not to use Java. In a properly designed language none of this applies. Take C++ for example. Initializing a static variable is - by definition - thread safe. The standard gives you this for free. Trying to access a static variable from multiple threads will just make them wait.
I don't see it as syntactic sugar only. It is a convenient way to make sure a certain initialization happens only once, where the code might be included - or even linked to - multiple times.
Admin
The scariest thing to me is that they might be calling the constructor in different places with different parameters.
Admin
Hahaha
pass on the bucket will you
Admin
The Java developers (both local and off-shore) that I have to work with really, really, really love a so-called Resources class. It contains static references to about anything you might be needing. I wish I had the authority to mete out corporal punishment for bad coding practices.
Admin
How art thou broken, let me count the ways.
Admin
1: True, but that does not make it an anti pattern. That makes it a pattern which should only be used in cases where you need to ensure that there is only one instance. This is sometimes exactly what you need.
2: You can't blame the pattern for the fact that someone implemented it badly. And the locking issue is not larger then for other objects you want to access in multiple threads. Besides synchronized in Java is really really cheep, as long as nobody holds the lock, so just making the method get() synchronized is not a problem. Remember we are talking about a language, where most methods in StringBuffer and Vector are synchronized*
But I don't see how caching causes problems for the gc. The singleton should not really be garbage collected in most cases because its lifetime will be the same as the program itself. But even if our singleton has a clear() method, why do you care exactly when it will be garbage collected. The exact time the object will be garbage collected, should not affect the program at all. Unless you have a finalize in the Singleton but in that case: Please submit to the daily wft, because that would be insane.
3: There is nothing difficult about testing the Singleton class itself. You just call get(), and test it as any other object you want to test.
Where you can get problems is that, if you are running multiple tests, they may change the singletons state, so in worst case a test might fail if and only if, an other test have been running before which changed the state of the singleton.
*Which as Sun realized was a major wft, so they created new classes with mostly the same methods, but no synchronization.
Admin
Misspelt words make good brand names, because they are Googleable. When you search such brand, it won't return zillions of completely unrelated results even if you don't further specify what about it you want. Given how many people don't remember domain names and rely on search it is an important advantage.
Admin
Which is why Microsoft really should have called it the Srfc.
Admin
Microsoft is large enough that they can afford not to follow this, because when they publish something, it will quickly gather enough links to make it to the first page of the generic search. Smaller companies don't.
Admin
Admin
The problem with singletons and testing is that the singleton winds up coupled to its clients, making it very hard to replace it with a mock, test implementation, or anything of the sort.
Admin
True, but many singletons don't need to be mocked. There's not much point in creating a mock for a method like HashSHA512(string s).
Admin
Google is shooting themselves in the foot, because googleable is a perfectly cromulent word:
[image]as is, of course, cromulent
[image]Admin
Show concrete examples of where there is a real world "type" that there should only ever be one instance in the universe. IT is a fallacy. There may be cases where you want to ensure things within a given environment/scope use the same instance - but this is not "the universe".
I agree about the implementation not being the issue. I was actually thinking .NET (where I have extensive experience) rather than Java (where I have moderate experience), so I will concede the point for Java Every variable that can hold a reference type must be examined during a Gen2 GC. Declare a variable, or field within an instance and even when it is set to null there is a (very tiny) impact on GC. It has nothing to do with the collection of the object itself, and (almost) everything to do with the work required to scan for what objects are reachable. [there is also the cost of an item being copied internally as it progresses through the generations]Try writing robust concurrent tests (many tests running at the same time) against a single instance. It is virtually impossible (if the object maintains any state - and if it is stateless, why is it an instance?). Speed of execution is critical for things such as gated check-in testing.
Admin
Just make it a doubleton then. Have 1 real implementation, and 1 test double. Problem solved. /s
Admin
But that doesn't need to be a singleton, either -- it's perfectly fine living on its own as a free function. ;)
:trolleybus: ?Admin
QFT. Half of the Holy Design Patterns™ exist to work around lack of more straightforward tools in Java. Conceptually they are used in other languages as well, but they are so trivial and obvious there that nobody bothers mentioning them.
Non-acknowledge. File-scoped and class-static variables are initialized during global startup and by then there usually are not other threads, so it is thread safe just because of that. But function-static variables are initialized on first invocation of the containing block and that is not thread-safe.
No, it will not. C++ does not synchronize anything on its own.
… and the first set of parameters will be used. Where which will be used first may not be well defined…
There is not much point in making a hashing function a singleton either. A static method is just fine for that.
Admin
And that assumes that you aren't trying to do some sort of lazy initialization.
Admin
Obviously, they're missing the SingletonSmtpClientFactoryFactory class... :trolleybus:
Admin
Static methods/fields are the sane implementation of the singleton concept. In any language that has static (including static initializers), I see no point in a traditional singleton.
My point was that if you did, for some reason, implement a hash function as a method of a singleton - it wouldn't make it hard to test.
Admin
From the C++11 spec, section 6.7:
When talking about function-scoped static variables, the memory for them is initialized on startup, however the constructor is only executed the first time the function gets called.
Admin
Many would argue that that is also wrong. Static has it's problems too. Ideally, if you need things to share a thing, you give them both the same thing. And you can give them a different thing when testing, if you do it right.
Admin
In this case (an SMTP client) it does makes sense to use a singleton... not this way of course.
Admin
Getting null if you call getInstance before calling the constructor is the obvious WTF. Personally, my favorite WTF in this was that if you call the constructor a second time, it silently does nothing. Null pointer exceptions are easy to see and fix, but silent no-ops cause all kinds of bugs that are hard to track down.
Admin
Exactly.
Admin
Hey, I'm on board with the whole "singleton pattern is stupid" idea. I was just saying that a common use of the bad pattern doesn't cause testing problems.
Admin
TRWTF is starting a variable name with an underscore. Ugh!
Admin
It's easy enough to fix that. Just put in a MessageBox call.
Admin
Aaauuugggghhhhhh!!!!
Please inquisitor, no more!
:-)
Admin
I agree, but it's a common practice. It's the default in Resharper for private fields, so it's caught on. Despite Resharper having a feature to make them a different color.
Admin
I wondered at that, when I found a "Constants.cs" file at the root of a project I inherited. 700 lines of
const string
declarations, for things that are just as easy (if not more so) to get "dynamically". In fact, very often these constants were used in flat script files to point to themselves, and typically consisted of things like:Admin
AFAICT it's not a really screenshot - notably, ℵ results and 0.π seconds, and also https://www.google.com/search?q=Googleable&oq=Googleable&aqs=chrome..69i57&sourceid=chrome&es_sm=93&ie=UTF-8
Admin
That looked like
SUBFEELUPURL
at first, and I wondered what sort of thing you were developing.:giggity:
Admin
tr :wtf: is that that's not LOOKUPUPDATE.
Admin
Oh... my... word... http://www.askqtp.com/2012/12/how-to-create-singleton-doubleton-n-ton.html
Talk about taking a (design|anti) pattern to the extreme...
I also remember this guy wrote about a doubleton and n-ton and defending its use. The original link I found from a comment from an older Daily WTF (http://thedailywtf.com/articles/comments/The-Doubleton-Patten).
http://www.codeproject.com/Articles/10335/Starting-from-the-Singleton-Design-Pattern-to-Expl
Too bad he deleted it (probably out of embarrassment)
Admin
It's OK, there are also
ADDLOOKUP
andCREATELOOKUP
consts in the same pattern. Apparently they wanted to program within the guise of verb-object-ID, but MVC made them actually use object-ID-verb.I don't know, personally I don't understand "do $this with $object whose ID is $this" as readily as "Using $object of ID $id, do $this"
Admin
Interesting point the first article said about where it might be necessary for singletons: A Window Manager should be more than a singleton, especially if you're running more than one desktop session under the same window manager, right? I would imagine things like Window's Fast User Switching (and whatever the equivalent for other OS's, sorry skips the mind) would be horribly difficult to implement if you couldn't separate sessions in the window/desktop manager because they're all in the same collection...
Or maybe I'm incorrect in how I think a Window Manager even works...
Admin
When I think about singletons, I'm always reminded of this chapter from Test-Driven Development By Example:
Yes, that's the entire chapter.
Admin
Two comments saying its great, one saying, "Wait, why?"
Admin
I actually use singletons a lot for game dev in Unity. I frequently have a GameManager or something like that as a singleton class which generally keeps track of overall game state.
The reason it's a singleton is:
1.) Because there is never a situation where I need more than one game manager. Just one will do fine. 2.) Because that's honestly the most performant way to get a reference to the game manager. The only other options are to stick my game manager in the scene and have my scripts find it with GameObject.Find by name (ew) or stick it in a static dictionary or something (which is obviously overkill if there's only ever one that exists)
Maybe they're an antipattern, but it's the cleanest way I can think of to express the idea of a singular overall game manager concept.
Admin
Give. Things. It.
Things locating their dependencies from elsewhere in the system, in no way observable when looking at the class definition displayed when you F12 to a DLL, is bad. Always. Having a static variable somewhere without the singleton enforcement would be better than what you have, but it's still bad.