Re: Automagic instantiation of singletons?
Re: Automagic instantiation of singletons?
- Subject: Re: Automagic instantiation of singletons?
- From: Christian Brunschen <email@hidden>
- Date: Fri, 18 Nov 2005 15:11:18 +0000
On 18 Nov 2005, at 13:50, Mike Morton wrote:
Jonathan --
Is there any way to persuade a singleton object to create itself?
I have a few singleton objects that need to exist throughout the
lifetime of the application, and am currently instantiating them
in my application controller's applicationDidFinishLaunching: method.
It would be nice if I didn't have to explicitly do this. My
initial thought was that you could do it through the singletons' +
(void)initialize method - but of course, this isn't called at
application startup - it's only called the first time you try and
access the object, so it still needs to be manually set up.
You could in theory use NSObject’s +load, and I’ve had good luck
with it, but the doc warns “you should avoid using load whenever
possible”:
http://developer.apple.com/documentation/Cocoa/Reference/
Foundation/ObjC_classic/Classes/NSObject.html#//apple_ref/doc/uid/
20000050-load
So I agree with Christian’s suggestion that you have your
application create objects. But instead of having each subclass
know how to create its shared instance, you can add the smarts to
NSObject with something like the code below.
I might be slightly hesitant to use that kind of code, in particular
if retrieval of the singleton instance is something that happens a
lot, because of the overhead of using a dictionary rather than a
simple pointer. Also, in the presence of isa swizzling (such as used
by the automagic Key-Value Observing code), you *might* end up with
multiple instances of the same singleton class (since you're using
the class name as the key into the dictionary); unlikely, but possible.
<digression>
Another thing is that it may be an interesting idea to, in the
singleton class, override -retain, -release and -autorelease to be no-
ops:
- (id) retain { return self; }
- (id) release { return self; }
- (id) autorelease { return self; }
After all, the singleton shouldn't ever be deallocated. Otherwise, a
client of this class could, in theory, over-release the shared
singleton instance, with interesting consequences. Also, making these
no-ops will speed up any code that does try to retain or (auto)
release the singleton, which operations are redundant anyway.
Of course, any (auto)release messages that would actually reduce the
singleton's retain count to 0 would really be a bug in their code and
the above no-op implementations of retain/release/autorelease could
be considered to simply hide the problem. Perhaps more useful would
be to simply override the singleton's -dealloc to raise a suitable
exception:
- (void) dealloc { [NSException raise:@"CannotDeallocateSingleton"
format:@"The singleton instance of class %@ can not be deallocated",
[self className]]; }
This would alert the client of the singleton instance if deallocation
was ever attempted.
</digression>
-- Mike
Best wishes,
// Christian Brunschen
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden