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: David Gimeno Gost <email@hidden>
- Date: Tue, 29 Nov 2005 00:51:20 +0100
On 28 Nov 2005, at 22:20, Ondra Cada wrote:
Oh sigh...
Agreed. :-)
Lets at least adhere to the conventions of the memory management
provided by the framework, whether singleton or not.
More or less all others are trying to point out to you that's exactly
what the overriding of memory management methods achieves.
No, overriding those methods does not achieve that. There is no need to
override those methods to achieve that. You get the correct behavior by
just requiring client code to follow Cocoa's memory management rules.
Actually, overriding those methods allows client code to break Cocoa's
memory management rules without a hitch.
+sharedInstance { static id myself=nil; if (!myself) myself=[[self
alloc] init]; return myself; }
That's a very valid *singleton* we just made here. It does not quite
adhere to the memory-management conventions though, or rather, it
does, alas breaking so the contract of being a singleton :)
It doesn't? Why?
Now, in some specific cases that may be a reason to adhere to them
*whilst* keeping the singleton contract. That means reimplementing
allocWithZone:, or init, or both, and also dealloc/retain/release.
Sometimes (actually pretty often--in my 15-year experience with
Cocoa/ObjC (of course, has not been called Cocoa thence :)--much more
often than not) it's best for a singleton never to be destroyed at
all: there's simply no need. Sometimes it might be removed and
re-created on demand. *Depends on the particular class*.
Exactly. That's what I've been saying from the very beginning. It
depends. So why use a restrictive implementation, when a more general
one requires less code to be written and less methods to be overridden?
With the approach I'm proposing you still don't have to deallocate the
singleton if you don't want to. It's not like you have to do anything
special to not deallocate it. Both existing client code and the
singleton's behavior would be exactly the same as with the current
approach promoted by Apple's sample code (assuming client code follows
Cocoa's memory management rules, that is).
Anyway, to use the *object deallocation* tool -- the dealloc method --
for the *application quit clean-up* -- is plain wrong. You are just
using a completely inappropriate tool;
Why?
Most often than not, disposal of resources should be decoupled from
application quit cleanup. App-quit cleanup is one possible reason
certain resources must be disposed of in a certain way, but it may not
be the only one. Moreover, you don't want to have to know whether it's
the only one. The object that manages the resources shouldn't be
concerned with the reasons those resources should be disposed of. All
the object should be concerned with is that it is no longer needed (for
whatever reasons) and, thus, the resources it manages should be
disposed of properly.
This is what -dealloc accomplishes. You just tell the object that
manage the resources that you no longer need it. You don't have to be
aware of what that object will do with the resources it manages, and
the object doesn't have to know why it is no longer needed. This
decoupling of responsibilities should always be a design goal, whether
singleton or not. It's for introducing the coupling that you should
require a very good reason, not the other way around.
app-quit cleanup is a very very different beast from object
deallocation.
And 'for' loops also are a very different beast, but that doesn't mean
you shouldn't use them to do the cleanup, does it?
There is nothing wrong about _using_ object deallocation to do the
app-quit cleanup. Disposal of resources by means of the destruction of
the objects that manage them is a well-known widely-used design pattern
in object oriented software development (not just C++). It decreases
coupling and increases encapsulation.
Regards.
_______________________________________________
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