Re: Proper way to create a singleton without @synchronized ?
Re: Proper way to create a singleton without @synchronized ?
- Subject: Re: Proper way to create a singleton without @synchronized ?
- From: Quincey Morris <email@hidden>
- Date: Sun, 17 Apr 2011 12:58:46 -0700
On Apr 17, 2011, at 12:04, WT wrote:
> On Apr 17, 2011, at 3:52 PM, Joanna Carter wrote:
>
>>
>> Tell me; maybe it's my background in other languages, but I would tend to use a "static class" as a singleton; or, at least, design a class with only class methods/properties, with static "fields" declared in the @implementation section of a class.
>>
>> Why this fascination with going to all the trouble of creating a singleton rather than using the "static class" approach?
> not a fascination, but simply a preference and being used to coding that way. As for the "static class" idea, what happens if you need/want to subclass that class? Then you have to search for and change all the places in your code base that refer to it.
1. Conceptually, I think Joanna is right. In practice, I've found that using the class as a singleton doesn't always serve the purpose -- though I can never remember the usage case that's a problem. I think it's something like trying to use a class object as a 'didEnd' selector delegate, where you end up wanting encapsulated instance variables.
OTOH, I'm not sure I understand your objection as expressed above. You can of course subclass a class (i.e. override class methods). Having to search for the class name seems no different from the case where you change the name of your singleton-getter-method. But let's not get side-tracked into that ...
2. FWIW, I'm generally with Kyle and others who are suggesting that trying to implement forced, generalized singleton-ness may be a practical un-necessity.
A while back, I asked on this list whether a singleton is an object that there *is* only one of, or it's an object that there *can be* only one of. The answer, from someone whose opinion I respect (and who is almost always right) was "is", not "can be".
So the issue being discussed in this thread is not how to create a singleton, but how to prevent the creation of a second object of the class, which is a different matter.
"Doctor, doctor, it hurts when I do that." "Then don't do that." It's not bad advice here.
The question is who you're trying to prevent from doing what. If you declare (publicly) neither a factory method nor an initializer, leaving your "sharedXxx" class method as the only way to obtain an instance of the class, then no one's going to create another object without a determined effort to contravene your API (unless I'm overlooking something obvious).
I understand that you're implementing forced, generalized singleton-ness as a matter of interest as much as anything else, and I'm not saying don't do it, but I am asking how it protects you ... from who? what? ... more effectively than the low-tech solution outlined above.
3. This thread really isn't about singletons at all. Looking back at your original post, it's really about thread-safe creation of shared objects:
On Apr 16, 2011, at 20:04, WT wrote:
> Among other things, I wanted to replace my usage of @synchronized singletons, and dispatch_once() seemed the perfect mechanism for that.
In that context, my question is: what's wrong with @synchronized? After all, it can't be a performance issue when it only happens once per singleton class. Why is @synchronized an imperfect mechanism?
That's a genuine question, not a snark.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden