On Sat, May 10, 2008 at 10:14 PM, Jim Correia <[EMAIL PROTECTED]> wrote: > 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.
Even in this case, all you need to do is override -init to return the shared object. Apple's sample code, showing overrides to -retain, -release, and other such methods, just serves to hide bugs in the calling code. Mike
_______________________________________________ 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]
