On May 10, 2008, at 1:43 AM, Chris Hanson wrote:
In general terms though, I'll still state that it's a bad idea to
enforce that an object be a singleton — especially if you're new to
the framework and memory management rules etc.
Rather, I'd treat being a singleton as a code smell, and try to ask
whether methods on the singleton instance should be class methods,
or whether a "shared" singleton would be useful while leaving room
for specific instances in the future (and specific instances to use
during unit testing). For one thing, enforced singletons are hard
to subclass and substitute; being able to do so is quite useful in
certain circumstances.
In many cases, enforcing the singleton-ness of an object is
unecessary. Convention + shared instance are often good enough.
I have written a couple of bona-fide, enforced singletons over the
course of time though. These are typically objects I want to
instantiate in a nib so that I can easily use target/action (or other
IB features) with the object. In this case, enforcing that only one
ever exist is necessary.
But it is an advanced, or at least specialized, usage; definitely not
the common case.
Jim
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
