RE: Is Apple's singleton sample code correct?
RE: Is Apple's singleton sample code correct?
- Subject: RE: Is Apple's singleton sample code correct?
- From: Jeff Laing <email@hidden>
- Date: Wed, 30 Nov 2005 12:11:12 +1100
> > Therefore it might be necessary to listen to the appropriate
> > notifications to do your cleanup; singleton or not.
>
> I know. I never meant otherwise. But when you get the notification you
> must call some method to do the clean up. What I'm saying is that,
> telling an object to release the resources it manages is semantically
> identical to destroying it in most cases (i.e. the existence of the
> object has no purpose after those resources have been released), so,
> instead of sending it a -doCleanUp message, I might as well send it a
> -release message.
Minor discussion at cross-purposes here, I feel.
I think whats being suggested by about 30% of the participants in this
thread is that the singleton register itself to listen for the
notifications.
I believe David is *not* suggesting this, but rather that your application
logic listen for the notification and call an appropriate method on the
singleton to tell it to go away. (Or perhaps have the application delegate
do it - either approach would work)
It is true that using [singleton release] instead of [singleton doCleanUp]
is more sensitive to coding problems elsewhere in your application - but if
you are going to argue that sort of theoretical scenario, what happens to
the objects that have erroneously retain'd the singleton if they try to
access it *after* the doCleanUp message was delivered - which they might do
during their own cleanup processing?
On the other hand, isn't it as clear as:
"Apple say you should not release something you didn't
{alloc|retain}"
As such, the external request to "cleanup" really shouldn't be done via
release, if you are trying to play by the memory usage rules.
Now, if you have an "internal" cleanup (ie, you don't tell the singleton to
cleanup, it works it out for itself by listening to notification), the
ball-game is different. Then, I don't see any reason not to put it all in
release. But I'd be inclined to have my notification listener send [self
release] then NSLog() loud and clear if the singleton didn't actually
disappear, to catch the external retain problem.
> This has several advantages. One of them is that the design of the
> application becomes less dependent on the development environment. You
> can use the same design pattern no matter what, ...
This is key to understanding the problem. Is the pattern a "singleton" or a
"Cocoa singleton"?
If the former, then its bad form to rely on Cocoa notifications.
If the latter, its no big deal, there is no way you'll be used in an
environment where the application notifications are not sent.
Hmmm, unless perhaps you're a singleton thats embedded inside an
"unloadable" plugin. But then you'd need to have some sort of unload
message anyway - does that make it a different "pattern" ?
Its going to remain fairly subjective as to whether "good design" involves
maintaining as clear a boundary as possible between your classes, or tying
them together in a mesh of inter-operating notifications. Personally, I
believe David has been arguing the former and I agree with him.
> Note that the sample code provided by Apple will likely be copied and
> used by many novices without really understanding its nasty side
> effects nor why are all those methods actually being overridden. I
> could understand the current situation if there was a trade-off that
> justified writing the singleton that way, but there is none.
Frankly, I think the same can be said about most Cocoa sample code - it
takes an awful lot of understanding about the inter-object-communications
behind the scenes to understand the ten lines of uncommented code the
samples present. Learning Cocoa by reading code is definitely "doing things
the hard way(tm)". I'll say nothing about bindings where you just get to
look at pictures.
_______________________________________________
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